00:29
<AnselmBradford>
hi all, I'm looking at the example for the "dirname" attribute in the specification 4.10.7.2.2
00:29
<AnselmBradford>
and the example has 'dirname="comment.dir"'
00:30
<AnselmBradford>
doesn't that mean there should be an input field in the form with the id='comment.dir'?
00:31
<AnselmBradford>
as dirname is supposed to specify the form control that contains directionality information for a particular input
00:31
<AnselmBradford>
here's the example: http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#the-dirname-attribute
00:31
<TabAtkins>
You misunderstand how it works. @dirname tells the form what name to use to submit the directionality of the input.
00:31
<TabAtkins>
The directionality of the input is inherent to the input itself; it's not given by another control.
00:33
<AnselmBradford>
TabAtkins: Thanks, yeah I'm confused by it... particularly this bit:
00:33
<AnselmBradford>
"A form control dirname attribute on a form control element enables the submission of the directionality of the element, and gives the name of the field that contains this value during form submission."
00:34
<TabAtkins>
"field" does not mean "form control". It means the key part of the form submission, like "example.com?key=value"
00:35
<AnselmBradford>
ahh, right okay
00:36
<AnselmBradford>
is this supported by any browsers... I can't seem to get the examples I've found to work?
00:36
<TabAtkins>
Don't think anyone does it yet.
00:37
<AnselmBradford>
okay, thanks, that makes sense now :)
00:37
<TabAtkins>
excellent
06:54
<Hixie>
othermaciej: thanks (re mail to public-html)
07:31
<annevk>
zcorpan, are you sure parsing is the problem?
07:31
<annevk>
zcorpan, and not say, the painting?
07:31
<annevk>
zcorpan, and layout
07:37
<annevk>
Hixie, which differences were removed?
07:37
<Hixie>
some paragraph that was only in the w3c copy was removed after someone filed a bug on it
07:38
<Hixie>
(it was a pretty meaningless paragraph)
07:38
<Hixie>
(with lots of errors)
07:44
<annevk>
doesn't HTML suggest using <pre><code>?
07:44
<annevk>
re: replacement <xmp>
08:44
<zcorpan>
Hixie: "To represent a block of computer code, the pre element can be used with a code element" http://www.whatwg.org/specs/web-apps/current-work/complete/grouping-content.html#the-pre-element
10:01
<annevk>
"Just make every object constructable, it'll work!"
10:01
<annevk>
tralalala
10:05
<zcorpan>
Hixie: thanks for fixing racyness with video
10:42
<annevk>
zcorpan, btw, see the logs
10:42
<annevk>
I doubt parsing is that slow
10:50
<jgraham>
annevk: If it is on XHR, how would painting or alyout make a difference?
10:51
<jgraham>
The original complaint was that getting responseXML was slow
10:52
<jgraham>
Which it could be if you XHR in tens of megabytes of document
10:58
<annevk>
I thought it was getting and inserting it
10:59
<jgraham>
Hmm, possibly I didn't read closely, I'm not sure. You would have thought that someone complaining would do basic profiling of where the slowness actually is
10:59
<jgraham>
But, yeah…
11:00
<hsivonen>
annevk: why is SVG fonts only on a "maybe" list for Acid3 update? after Mozilla and Microsoft refusing to implement and after seeing that Opera and WebKit aren't aiming for a complete impl
11:00
<hsivonen>
(and the typical arguments in favor of SVG fonts assume a complete impl)
11:00
<annevk>
I did not put it there
11:00
<jgraham>
Today's lesson: living standards need living testsuites
11:03
<hsivonen>
so about 15% of Acid3 is suspect
11:04
<annevk>
If you go by the number of tests, but the actual problems are within those tests, so it's probably more like 5%
11:05
<annevk>
Well, SVG Animation and SVG Fonts are 5% together, so a little more
11:08
<annevk>
So the political party I support just launched a magazine fully in Flash. Uh what.
11:09
<hsivonen>
annevk: I guess you have to stop voting for them now.
11:10
<smaug____>
dropping SVG animation is new to me
11:12
<zcorpan>
annevk: what was it about parsing?
11:12
<zcorpan>
oh, async api?
11:12
<annevk>
zcorpan, yes
11:13
<zcorpan>
i thought the use case didn't involve layout at all but just parse a big chunk of xml
11:13
<zcorpan>
the bug said that the parsing operation was blocking the main thread and that was a problem
11:14
<zcorpan>
but we need to study use cases before designing new apis...
11:15
<zcorpan>
maybe we should have a way to parse right into an element in an async way so that it gets rendered incrementally if the use case is to get it on the screen
11:15
<annevk>
EV fail / Apple fail: http://www.computerworld.com/s/article/9219669/Mac_OS_X_can_t_properly_revoke_dodgy_digital_certificates
11:16
<annevk>
By the way, is there any copy of HTML still alive that has that data provider idea still in it?
11:16
<annevk>
I think Philip` experimented a bit with it and then it got removed
11:16
<annevk>
So not <datagrid>, but the other one
11:17
<zcorpan>
the repetition template replacement?
11:18
<annevk>
yeah maybe
11:20
<jgraham>
The one that 3 people understood?
11:22
<zcorpan>
i think it's not kept alive anywhere
11:23
<zcorpan>
if you want it you need to find a rev that has it
11:24
<annevk>
damn it
11:25
<annevk>
data templates
11:25
<annevk>
http://html5.org/r/2319
12:04
<zcorpan>
removing SMIL from SVG seems overly optimistic
12:05
<zcorpan>
maybe SMIL in SVG can be simplified but i doubt it can be removed altogether at this point
12:08
<zcorpan>
heh http://xkcd.com/949/
12:08
<annevk>
see publix-fx
12:08
<annevk>
also Microsoft does not support it
12:10
<annevk>
Yet another language from Google: http://gotocon.com/aarhus-2011/presentation/Opening%20Keynote:%20Dart,%20a%20new%20programming%20language%20for%20structured%20web%20programming
12:13
<annevk>
More on Dart here: http://markmail.org/message/uro3jtoitlmq6x7t
12:18
<wilhelm>
… Computational theologist.
12:21
<jgraham>
Is it only me that is reminded of ES4?
12:21
<jgraham>
I wonder if Google will succeed where Mozilla failed
12:25
<annevk>
I also wonder how they intend this fork to work.
12:25
<annevk>
Switching the scripting language on a page might be tricky.
12:27
<jgraham>
Allowing javascript and another language to both operate on the same page seems… tricky
12:27
<jgraham>
Using a "first langauge wins" policy might be easier
12:27
<jgraham>
But it makes it even harder to deploy
12:28
<Philip`>
jgraham: I thought the problem with ES4 is that browser vendors couldn't agree on it, which Google seems to be avoiding by being willing to do everything itself
12:28
<jgraham>
I thought the problem was the Microsoft vetod it
12:29
<jgraham>
I assume that Google won't implement it for IE
12:29
<Philip`>
(Then other vendors will be pressured into implementing it so that Gmail isn't much slower in their browser than in Chrome)
12:29
<jgraham>
Well that is the interesting thing
12:29
<jgraham>
Whether people will have to implement it because of Google properties
12:31
<benjoffe>
has twitter made a public statement as to why they're preferring '#!' urls over using the html5 history api?
12:32
<benjoffe>
I mean they have full time front-end devs, this must be intentional
12:32
<miketaylr>
they blogged once about some bug in safari's implementation
12:32
<miketaylr>
http://www.adequatelygood.com/2011/2/Thoughts-on-the-Hashbang
12:33
<miketaylr>
hmm maybe wrong link
12:39
<zcorpan>
annevk2: should getElementsByTagNameNS use [TreatNullAs=Empty] for the first argument?
12:40
<annevk>
namespaceURI returns null never the empty string
12:40
<annevk>
so we want to treat the empty string as null
12:40
<annevk>
not the other way around...
12:41
<annevk>
next time we design this API namespaceURI would return the empty string of course
12:47
<zcorpan>
i don't follow. my question is if we want teh following to be equivalent: ...NS(null, 'foo') and ...NS('', 'foo')
12:47
<zcorpan>
or ...NS(null, 'foo') and ...NS('null', 'foo')
12:51
<annevk>
the former I think with the empty string being treated as null
12:51
<annevk>
does seem like that requires changes
12:53
<annevk>
see http://www.w3.org/TR/DOM-Level-3-Core/core.html#Namespaces-Considerations :(
12:54
<annevk>
"In programming languages where empty strings can be differentiated from null, empty strings, when given as a namespace URI, are converted to null."
12:54
<annevk>
So all NS-methods need to be changed to accepting "DOMString?" and the corresponding algorithms need to match
12:55
<annevk>
Do you agree?
12:55
<annevk>
e.g. this is a problem for createElement etc. too
12:56
<annevk>
hmm
12:57
<annevk>
i see elsewhere we use [TreatNullAs=Empty] and then in the algorithm change empty to null
12:57
<zcorpan>
yeah
12:57
<annevk>
TreatEmptyAs=Null would be cool
12:58
<annevk>
or DOMStringNS :p
12:58
<zcorpan>
whether we use DOMString? or [TreatNullAs=Empty] seems like an editorial issue
12:58
<annevk>
I think I will go with DOMString? then
12:59
<annevk>
so you don't need double-conversion if your implementation generates stuff based on the IDL
13:21
<annevk>
http://www.mnot.net/blog/2011/08/24/distributed_hungarian_notation_doesnt_work
13:21
<annevk>
Instead of using Sec- to prevent XMLHttpRequest clients, update the list of headers to block by XMLHttpRequest and have aggressive browser update cycles...
13:24
<Philip`>
Doesn't need to be part of the browser upgrade cycle, it could just be a centrally-located list that they download every few days
13:26
<annevk>
It seems rather complicated though
13:27
<annevk>
But maybe it's worth it, Sec- isn't everything either
13:28
<jgraham>
It feels a bit fragile
13:32
<heycam>
just dropping in to say I'm on vacation for the next 4 weeks, see you all later
13:33
<jgraham>
It's not nice to gloat :p
13:33
heycam
smiles, waves
13:34
<annevk>
zcorpan, changed the specification
13:35
<annevk>
Damn it, now I can't complain about exceptions for a month
13:35
<annevk>
Maybe I should go on vacation too :)
13:35
<jgraham>
You can *complain*
14:57
<donri>
i'm sure this has been asked before so please excuse me :) why does html5 keep the form[@method] restriction and leave out other useful verbs?
14:58
<annevk>
because other verbs would need a same-origin restriction
14:58
<donri>
is it different from POST?
14:58
<annevk>
and because we could not figure out the details of how that would work
14:59
<annevk>
to deployed servers everything is different from POST/GET when it comes to requests carrying cookies
14:59
<annevk>
or to requests where you identify with IP address or some such
15:01
<donri>
not sure i understand. isn't it up to the application that probably also sent the form?
15:06
<annevk>
donri, those are same-origin typically
15:06
<annevk>
with cross-origin all bets are off
15:07
<annevk>
and forms can request cross-origin by default, so changing what they can request is dangerous
15:08
<donri>
don't quite see the issue if it's a different method to have different behavior but ok, thanks ):
15:08
<donri>
:) *
16:02
<AryehGregor>
zcorpan, I'd reply, but you vanished. :( Not sure what the context of your message was: is this review of the spec, or explanation of Opera's behavior, or whaT?
16:02
<AryehGregor>
what?
16:02
<annevk>
http://www.guardian.co.uk/books/2011/sep/07/michael-moore-hated-man-america is terrible, but "You ever see a Navy Seal get stabbed? The look on their face is the one we have when we discover we're out of shampoo." is pretty funny
16:20
<timeless>
hrm, webidl people?
16:21
<timeless>
[Callback=FunctionOnly, NoInterfaceObject] interface MyCallback { void looped(); }
16:22
<timeless>
interface Silly { [Constructor] Silly([TreatNonCallableAsNull] MyCallback looped); }
16:22
<timeless>
afaict, that isn't allowed and probably isn't allowed for a couple of reasons
16:22
<timeless>
none of which seem good
16:23
<timeless>
grr, no heycam either?
16:24
<Philip`>
timeless: "13:35 < heycam> just dropping in to say I'm on vacation for the next 4 weeks, see you all later"
16:24
<timeless>
Philip`: thanks
16:24
<timeless>
Philip`: do you happen to speak webidl at all? :)
16:25
<timeless>
or perhaps jwalden ?
16:25
<Philip`>
Only the really easy bits
16:25
<jwalden>
timeless: not fluently, I've only really interacted with it to the extent needed to describe how it affects JS bindings
16:25
<timeless>
that should be sufficient
16:26
<jwalden>
and even there it's been more hands-offish
16:26
<timeless>
can i get you to consider:
16:26
<timeless>
[Callback=FunctionOnly, NoInterfaceObject] interface MyCallback { void looped(); }
16:26
<timeless>
interface Silly { [Constructor] Silly([TreatNonCallableAsNull] MyCallback looped); }
16:27
<jwalden>
these verbs may exceed my vocabulary, but go on
16:27
<timeless>
so...
16:27
<timeless>
use case, i want to have a Silly interface which demands a MyCallback
16:27
<timeless>
it doesn't want a null MyCallback, that would be too silly
16:27
<timeless>
oh, hrm
16:28
<timeless>
i guess i don't need treatnoncallableasnull
16:28
<timeless>
because normally it'd just get a type error
16:28
timeless
is too used to JS coersion in gecko
16:28
<timeless>
ok, ... some handwaving as i change my example :)
16:30
<timeless>
assume i was ok w/ people passing garbage, so i had s/MyCallback looped/MyCallback? looped/
16:31
timeless
sighs
16:31
timeless
rewrites the example
16:31
<timeless>
thanks for listening :)
16:38
<dglazkov|away>
good morning, Whatwg!
18:30
<jgraham>
OK, this is not hard people
18:31
<jgraham>
If, for whatever dumb reason, you decide to use tabs to indent in a file
18:31
<jgraham>
and you have one line of code that is split over multiple lines in the file
18:32
<jgraham>
and, for aesthetic reasons you want some special alignment on the lines that doesn't correspond to a whole number of tabstops at the start of each line
18:32
<jgraham>
You have to use *tabs then spaces* to get the right alignment
18:32
<jgraham>
*not just spaces at whatever retarded tab width you happen to be using*
18:33
<jgraham>
Alternatively *avoid the whole problem* and *don't use tabs*
18:33
<jgraham>
Thank you
19:02
<Hixie>
wait, <xmp> is display:block? damnit i always forget that.
19:18
<zewt>
jgraham: welcome to pointless waste-of-time holy war
19:19
<zewt>
make sure your tabs are on the standard multiple-of-8-spaces so it works everywhere and move on with life
19:39
<Hixie>
anyone know about 'caller' being removed? do i just have to remove 'caller' from all my IDLs and then add this for document.all?:
19:39
<Hixie>
<p>In addition to the above, <code>HTMLAllCollection</code> objects,
19:39
<Hixie>
in JavaScript, must be callable. Calling such an object must
19:39
<Hixie>
implicitly invoke the index getter with the same arguments.</p>
20:20
<TabAtkins>
jgraham: Alternately, use tabs like a sane person, and let your code editor intelligently do a visual wrap for you.
20:20
<TabAtkins>
jgraham: But otherwise, yes, a thousand times yes, tab to the same indent, then use spaces.
20:30
<Hixie>
TabAtkins: would you be interested in giving a talk at https://sites.google.com/site/doceng2011/symposium/workshops ? it's at google
20:30
<Hixie>
or anyone else for that matter
20:33
<TabAtkins>
Hixie: Looking at th eother talks, I don't think I can contribute anything topical.
20:45
<Hixie>
they're just looking for someone who can give an "inspirational talk" on html5
20:48
<Hixie>
what's the right list to e-mail to get input on browser vendors' future plans regarding svg?
20:48
<Hixie>
www-svg?
20:48
<Hixie>
public-svg?
20:50
<shepazu>
www-svg, I'd think
20:52
<Hixie>
k
22:27
<AryehGregor>
Ouch, I didn't even think of this: http://www.daemonology.net/blog/2011-09-01-Iran-forged-the-wrong-SSL-certificate.html
22:30
<AryehGregor>
(Chrome isn't vulnerable, of course, due to cert pinning)
22:45
<zewt>
personally, i'm not thrilled about the idea of giving google the ability to run scripts on all of those sites in the first place
22:45
<AryehGregor>
There's not much alternative if you want the functionality.
22:50
<zewt>
there could be; maybe if there was a way of creating cross-origin workers
22:57
<AryehGregor>
How would that help?
22:57
<AryehGregor>
What might make sense is putting it in an iframe instead of a <script>.
22:58
<AryehGregor>
I assume there's some reason they don't do that, though.
22:58
<AryehGregor>
Realistically, it's a convenience-security tradeoff that leans toward convenience for almost all sites.
23:00
<zewt>
well, a sandboxed API (messaging)
23:00
<zewt>
there's also a performance tradeoff, though, which I'm sure is critical for GA
23:21
<Hixie>
jgraham: 504 again
23:38
<Hixie>
does hallvord ever hang out on irc?
23:39
<zewt>
MICROSOFT PROPOSAL: Close the bug - This bug is from an anonymous contributor ...
23:39
<zewt>
heh
23:40
<Hixie>
annevk: you around?
23:40
<Hixie>
what is it i have to do to make events constructible again?