| 00:29 | <AryehGregor> | Adobe is getting really worked up about this Apple thing. |
| 00:29 | <AryehGregor> | It surprises me. |
| 00:29 | <AryehGregor> | Why don't they just avoid having anything to do with Apple and move on? Is a PR campaign going to help them in any way? |
| 01:19 | <Philip`> | AryehGregor: Maybe the hope is that they will convince Apple customers to demand Flash support so strongly that Apple has to give in |
| 01:19 | <Philip`> | Flash only works because it's ubiquitous, and if it doesn't work on iPhones then it will no longer be ubiquitous and so it will be hugely less useful, and so they have to try hard to fight against that |
| 01:26 | <jwm> | hehe |
| 01:26 | <jwm> | web tech just needs a kick in the butt |
| 01:26 | <jwm> | adobe should try to just support the web tech instead |
| 01:26 | <jwm> | but whatever |
| 07:37 | <gsnedders> | Hi y'all. |
| 07:38 | <gsnedders> | brucel was asking me about changing the "untilted section" in the outliner, on grounds that a lot of people take that to mean that nav/aside/etc. must have headings. Ideas? Thoughts? |
| 07:40 | <Hixie> | for nav, you could call it Navigation instead of Untitled |
| 07:40 | <nimbu> | gsnedders: please do! It makes me feel like my code is incorrect :( |
| 07:42 | <gsnedders> | Hixie: And aside? |
| 07:42 | <Hixie> | gsnedders: Sidebar? |
| 07:47 | <gsnedders> | I guess I could special case article as well |
| 07:49 | <gsnedders> | Hixie: Untitled Sidebar, or Sidebar? I'm really quite fond of making it explicit why it's giving that text |
| 07:49 | <Hixie> | what's the use case for your tool? |
| 07:51 | <gsnedders> | People wanting to see what outline their page creates for the purposes of ensuring they get the outline they expect from their markup |
| 07:52 | <Hixie> | i'd expect a UI to not distinguish fake headings from real headings |
| 07:53 | <Hixie> | so if you're tryign to emulate a UI... |
| 07:53 | <gsnedders> | I'm not sure whether I should emulate a UI or whether I should show explicitly what is fake and what is not for the sake of helping developers… |
| 07:54 | <Hixie> | you could just style fake headings differently |
| 08:59 | <hsivonen> | whoa. the string "XHTML5" is nowhere to be found in current-work/ |
| 08:59 | <hsivonen> | Hixie: what's up with that? |
| 09:00 | <Hixie> | where should it appear? |
| 09:01 | <Hixie> | The string "HTML5" doesn't really appear either |
| 09:01 | <Hixie> | only in examples, references to other specifications, and text talking about the history or talking about what is or isn't html5 |
| 09:02 | <Hixie> | whatwg has moved on from (x)html5 |
| 09:05 | <hsivonen> | Hixie: well, I expected it to occur *somewhere* |
| 09:06 | <hsivonen> | Hixie: I was looking for spec text binding the definition of "XHTML5" to the content type |
| 09:06 | <Hixie> | XHTML5 is obsolete from the point of view of the whatwg spec |
| 09:06 | <hsivonen> | Hixie: I see |
| 09:06 | <Hixie> | so it wouldn't be bound to anything |
| 09:06 | <Hixie> | the content type binds to just "xhtml" |
| 09:06 | <hsivonen> | ok |
| 09:07 | <Hixie> | http://www.whatwg.org/specs/web-apps/current-work/#application/xhtml+xml |
| 09:12 | <annevk> | it should prolly just bind to XML as binding to XHTML has hopefully no special side effects |
| 09:12 | <Hixie> | it pretty much does, see the link above |
| 09:14 | <annevk> | ah right |
| 09:22 | <othermaciej> | it's a shame that the XHTML entity hack is tied to the doctype instead of the MIME type |
| 09:22 | <hsivonen> | othermaciej: binding it to the MIME type would be wrong per XML |
| 09:23 | <othermaciej> | hsivonen: I'm speaking here in terms of what approach would yield more practical benefits, rather than what approach has greater XML-theoretical purity |
| 09:23 | <hsivonen> | my bad |
| 09:24 | <annevk> | volkmar, regarding the form="" attribute email; you can implement things however you wish, as long as they're in line with the spec |
| 09:25 | <annevk> | MIME type would be annoying too |
| 09:25 | <annevk> | MIME types are wrong for XML in general |
| 09:25 | <annevk> | What MIME type to use if you mix SVG and XHTML? |
| 09:26 | <Hixie> | mime types are wrong in general |
| 09:26 | <othermaciej> | I would pick whichever is the root element |
| 09:26 | <annevk> | If it were to depend on the root element your entities plan would already fail |
| 09:26 | <Hixie> | magic strings would hae been better |
| 09:26 | <annevk> | Yeah |
| 09:26 | <Hixie> | (reliably magic strings, not the sniffing crap we have ended up with) |
| 09:26 | <othermaciej> | in the current environment anyway |
| 09:26 | <othermaciej> | agree, in-band typing is batter |
| 09:26 | <othermaciej> | but it's hard to do effectively and soundly in text-based formats |
| 09:27 | <othermaciej> | *better |
| 09:27 | <Hixie> | not really |
| 09:27 | <Hixie> | look at cache manifests |
| 09:27 | <Hixie> | they haveone |
| 09:27 | <othermaciej> | the collision with text/plain is the problem |
| 09:28 | <othermaciej> | if text/plain had its own distinct magic string the approach would be viable, but it doesn't, and can validly include any imaginable text-based magic string |
| 09:31 | <Hixie> | in this world there is no text/plain |
| 09:31 | <annevk> | <plaintext> :) |
| 09:31 | <Hixie> | since text/plain is a mime type |
| 09:32 | <annevk> | the WebSocket over TLS sounds somewhat nice |
| 09:32 | <othermaciej> | how would one serve plain text content in this world? |
| 09:32 | <annevk> | with a non-TLS-HTTP fallback that's even simpler than with the current handshake |
| 09:32 | <othermaciej> | TLS-only sounds like the sanest solution so far |
| 09:32 | <othermaciej> | I still haven't heard a compelling use case for a non-TLS version |
| 09:32 | <Hixie> | othermaciej: either use <plaintext> as anne suggested, or just rely on it not having a matching magic string |
| 09:33 | Hixie | is really not eager to require people understand TLS libraries |
| 09:33 | <othermaciej> | Hixie: did you see the 15-line TLS echo server I posted in Python? |
| 09:33 | <MikeSmith> | SPDY is TLS-only, right? |
| 09:33 | <Hixie> | python isn't the only language |
| 09:33 | <othermaciej> | granted, you'd need to understand a tiny bit more TLS to use whatever library's support for connego |
| 09:34 | <othermaciej> | sure, but it's a good example of a modern, well-maintained language of interest to "hobbyists" |
| 09:34 | <Hixie> | the thing with TLS is that to use it safely you can't just rely on a vague understanding |
| 09:34 | <othermaciej> | I imagine Ruby and Perl have libraries that are similar in spirit |
| 09:35 | <Hixie> | you have to worry about certs and all kinds of crap |
| 09:35 | <hsivonen> | Hixie: PHP isn't great for maintaining persistent connections anyway |
| 09:35 | <Hixie> | it's trivial to misconfigure this kind of thing |
| 09:35 | <Hixie> | hsivonen: php isn't great for much of anything |
| 09:35 | <othermaciej> | Adam's proposal was that wss: would use full TLS for real, and ws: would allow unverified certs and not really be secure |
| 09:35 | <othermaciej> | (thus making it no worse than using a non-SSL solution) |
| 09:36 | <Hixie> | i'm pretty sure i could implement websocket as it stands today in pretty much any unix-based language, including probably shell scripting |
| 09:36 | <othermaciej> | of course, a flaw with that is you don't want someone to use ws: to connect to your wss: service |
| 09:37 | <othermaciej> | I'm pretty sure you could |
| 09:37 | <Hixie> | adding TLS as a requirement is several orders of magnitude more complexity |
| 09:37 | <Hixie> | i'm honestly not sure i could use websocket with freepascal for example, if TLS was required |
| 09:37 | <othermaciej> | I haven't studied libraries for other languages enough, but it's clear that in Python using TLS is not a great burden |
| 09:38 | <othermaciej> | freepascal is so far on the long tail of implementation languages that I don't really care if it is easy to use to code a server from scratch |
| 09:38 | <othermaciej> | anyone using it has already chosen to make their life hard |
| 09:39 | <gregw> | othermaciej: I think general TLS libraries are pretty easy to use (a bit more complex on server side). But most are lazy with memory and will lower the barrier to when fancy scalable solutions are needed |
| 09:39 | <othermaciej> | also: a "hobbyist" should never under any circumstances implement a network service in a language with raw memory access |
| 09:39 | <Hixie> | well given that i've written a websocket server in freepascal already, i think it's relevant :-) |
| 09:39 | <othermaciej> | maybe relevant to you personally |
| 09:39 | <Hixie> | well yes |
| 09:39 | <othermaciej> | but I think the number of other people in the world who would care is in the single digits |
| 09:39 | <annevk> | Can you deploy the Python TLS on e.g. DreamHost without having to buy things like static IP and certificate nonsense? |
| 09:40 | <Hixie> | i'd probably have to write a binding to the openssl C library |
| 09:40 | <Hixie> | which sounds like a minor circle of hell |
| 09:40 | <othermaciej> | I don't think you need a static IP, and I don't think you have to pay for a cert under Adam's proposal |
| 09:40 | <hsivonen> | Hixie: frankly, the freepascal argument feels a lot like the using Delphi as a reason to make the DOM suck more in the old days |
| 09:40 | <othermaciej> | gee, obscure language doesn't have good availability of libraries? I'm shocked |
| 09:40 | <hsivonen> | s/the/ |
| 09:40 | <hsivonen> | s/the// |
| 09:41 | <Hixie> | hsivonen: how would delphi make the DOM suck more? |
| 09:41 | <hsivonen> | Hixie: inability to represent null strings, IIRC |
| 09:41 | <othermaciej> | gregw: I'm curious how much the memory hit is - that seems like useful data |
| 09:41 | <hsivonen> | or something of that nature |
| 09:41 | <Hixie> | hsivonen: delphi can represent null strings fine |
| 09:41 | <annevk> | othermaciej, ok, if it works in DreamHost with e.g. Python or Perl and is relatively straightforward I'm good... |
| 09:41 | <othermaciej> | if the argument is hobbyists who would implement a network protocol themselves, then any language with raw pointers is a red herring |
| 09:41 | <gregw> | with java it is currently 128k extra per connection |
| 09:42 | <othermaciej> | it's a feature if a hobbyist can't figure out how to use such a language to make a network service |
| 09:42 | <Hixie> | othermaciej: i'm not arguing that hobbyists would use freepascal, i'm arguing that i have used freepascal |
| 09:42 | <gregw> | you can be smart and avoid this, but it is a major "circle of hell" to do so |
| 09:42 | <Hixie> | othermaciej: and i personally would find it a pain if we had to use tls |
| 09:42 | <Hixie> | othermaciej: in generaly though, not specifically for my own concerns, i think it's a bit weird to require something as complicated as TLS for a simple protocol |
| 09:43 | <hsivonen> | Hixie: http://lists.w3.org/Archives/Public/www-dom/2005OctDec/0019.html |
| 09:43 | <othermaciej> | Hixie: much though I love you, I am not sure I can justify implementing an alternate WebSocket handshake solely for your personal convenience |
| 09:43 | <Hixie> | hsivonen: that poster is mistaken |
| 09:43 | <hsivonen> | Hixie: ok |
| 09:43 | <othermaciej> | gregw: 128k per connection is not so good |
| 09:44 | <Hixie> | hsivonen: (you can just use a pointer to a string if that's what you want) |
| 09:44 | <othermaciej> | gregw: that would be, like, a gig of memory for 8096 connections |
| 09:44 | <othermaciej> | gregw: is that really right? that seems totally unworkable |
| 09:45 | <othermaciej> | excuse me, 8192 |
| 09:45 | <gregw> | the java SSLSession tells you how big your buffers should be and currently reports 64k for in and out. |
| 09:45 | <Hixie> | othermaciej: my own personal convenience isn't why i'm arguing against it |
| 09:45 | <Hixie> | othermaciej: it's just a minor side-comment |
| 09:45 | <othermaciej> | ok |
| 09:45 | <gregw> | it might be able to be reduced... but not obvious how |
| 09:45 | <gregw> | the solution is to not allocate buffers to connections - but is very complex to do |
| 09:46 | <gregw> | we will be doing this anyway, just for HTTP |
| 09:46 | <gregw> | but it's not something trivial |
| 09:46 | <gregw> | it will push more medium sized servers to complex solutions |
| 09:46 | Hixie | tries to find out how to do TLS from Perl |
| 09:47 | <gregw> | but there are many servers that will never have more than 100 connections. |
| 09:47 | <gregw> | but even that is a lot of memory for buffers |
| 09:47 | <othermaciej> | does the canonical way to do a non-TLS socket in Java allocate such large buffers? |
| 09:47 | <gregw> | I'm 95% sure... I'll go check the source.... back in a bit |
| 09:47 | <othermaciej> | what are the buffers for? |
| 09:48 | <othermaciej> | I don't know enough Java to do an experiment of measuring the actual memory increase |
| 09:48 | Hixie | tries to work out from http://search.cpan.org/~sullr/IO-Socket-SSL-1.33/SSL.pm how to say what the next protocol is |
| 09:49 | <Hixie> | i should clarify that if i wasn't worried about amateurs, i'd have never even suggested a non-encrypted version of the protocol |
| 09:49 | <Hixie> | obviously encrypting the connection is a huge win in many respects |
| 09:49 | <Hixie> | but i honestly can't see your average author understanding SSL, even if it's through a library |
| 09:50 | <othermaciej> | I don't think you need to understand SSL to use it through a (simple enough) library any more than you need to understand TCP to use sockets |
| 09:51 | <Hixie> | there's a lot more complexity in SSL than in TCP |
| 09:51 | <othermaciej> | internally, yes |
| 09:51 | <othermaciej> | exposed to a relatively simple user of the protocol via a library, only a little more, I think |
| 09:52 | <othermaciej> | again, I am struck by the Twisted example |
| 09:52 | <Hixie> | externally too! look at the definition of the Perl IO::Socket::SSL API: http://search.cpan.org/~sullr/IO-Socket-SSL-1.33/SSL.pm#The_Long_of_It_%28Detail%29 |
| 09:52 | <othermaciej> | I did not expect it to be so simple |
| 09:52 | <gregw> | othermaciej: the buffers are for separating unecrypted data from encrypted data. The TLS protocol takes discrete chunks of data so that at any given time you can have unconsumed raw data and unflushed encrypted data |
| 09:52 | <othermaciej> | Hixie: is that significantly more complicated than this: http://linux.die.net/man/2/connect |
| 09:53 | <gregw> | plus you need buffers for TLS to do it's own control frames |
| 09:53 | <Hixie> | othermaciej: yes? |
| 09:53 | <othermaciej> | either the Perl IO::Socket::SSL API or connect(2) are interfaces you would really want to use through a higer-level wrapper |
| 09:54 | <Hixie> | othermaciej: IO::Socket::SSL _is_ the higher-level wrapper |
| 09:55 | <Hixie> | othermaciej: the next higher level is just a Web Socket library |
| 09:55 | <othermaciej> | Hixie: it's not a very good wrapper compared to Twisted |
| 09:55 | <Hixie> | othermaciej: that's as may be |
| 09:55 | <othermaciej> | Twisted is higher level but still generic to any kind of network protocol you want to build |
| 09:55 | <Hixie> | othermaciej: though to be honest i haven't been able to find how to tell twisted to declare the next level protocol either |
| 09:55 | <Hixie> | othermaciej: i don't think we should be relying on libraries to make this implementable any more than we should rely on tools to make html authorable |
| 09:55 | <gregw> | othermaciej: initial TLS usage can be simple, but it quickly escalates into key stores and trust stores and certificate chains etc |
| 09:55 | <Hixie> | "the tools will save us" imho is not a valid argument in either case |
| 09:56 | <othermaciej> | I suspect since next_protocol_negotiation is pretty new it hasn't filtered into all the libraries yet |
| 09:56 | <othermaciej> | connect() or gethostbyaddr() are just as much tools as TLS is |
| 09:56 | <Hixie> | i disagree |
| 09:56 | <othermaciej> | you think unix system calls don't count as an API you have to learn? |
| 09:57 | <Hixie> | i think unix system calls are the equivalent of "bare metal" compared to third-party libraries |
| 09:58 | <othermaciej> | it's not like socket() + listen() + accept() is an intuitive set of calls that everyone will figure out instantly |
| 09:58 | <annevk> | is a second handshake really that complicated though? |
| 09:58 | <othermaciej> | the fact that they come with the operating system does not free a developer from the burden of understanding them |
| 09:59 | <othermaciej> | making it robust against cross-protocol attacks is complicated |
| 09:59 | <othermaciej> | but it can be simpler than it is now if it doesn't have to work over port 80 or on any port shared with an HTTP server |
| 10:00 | <annevk> | in the end it's just a bit of parsing, calculating, and writing something back |
| 10:00 | <annevk> | seems trivial compared to e.g. layout :) |
| 10:00 | <othermaciej> | sure, but I wouldn't add a second layout engine either... |
| 10:06 | <gregw> | othermaciej: I can't find the source in openJDK that handles the crypto buffers - will download full source later and look again. But I am 95% sure it uses the same mechanism underneath and thus would have the same buffer sizes. |
| 10:07 | <othermaciej> | gregw: what I'm really curious about is the comparitive memory overhead of a normal (non-SSL) socket and what exactly the large buffers are for |
| 10:08 | <gregw> | othermaciej: OK, I'll find out the exact numbers over the weekend. |
| 10:12 | <MikeSmith> | othermaciej: I see that the Qt port now has MathML support.. is there porting/platform work that yet needs to be done to enable MathML in Safari? |
| 10:12 | <othermaciej> | MikeSmith: not as far as I know |
| 10:12 | <othermaciej> | does it work in nightlies? |
| 10:12 | othermaciej | can't remember if anyone enabled it by default |
| 10:13 | <MikeSmith> | didn't work in nightlies, not last time I checked |
| 10:13 | <MikeSmith> | but I'll try it again now |
| 10:14 | <MikeSmith> | ah, I was confused |
| 10:14 | <MikeSmith> | was testing with http://hsivonen.iki.fi/test/moz/html5-hacks-demo.html but of course that's not going to work yet in WebKit |
| 10:15 | <MikeSmith> | because it requires MathML-in-text/html support |
| 10:16 | <MikeSmith> | hmm, still doesn't seem to be working though, even for tests served as XML |
| 10:17 | <othermaciej> | it might not be turned on yet |
| 10:17 | <othermaciej> | there is a build flag |
| 10:18 | <MikeSmith> | ok |
| 10:19 | <annevk> | MikeSmith, you look surprisingly weird without the stache :p |
| 10:21 | <MikeSmith> | annevk: yeh, I'm regretting it already |
| 10:23 | <MikeSmith> | I was in need of a new look, anyway |
| 10:23 | <MikeSmith> | I'm like Madonna that way |
| 10:23 | <MikeSmith> | need to keep my fans from getting bored |
| 10:25 | <MikeSmith> | man, my inbox situation is just out of hand |
| 10:25 | <MikeSmith> | the world should do something about that for me |
| 10:26 | <MikeSmith> | we really need something like a Worldwide Day of No E-mail |
| 10:26 | <annevk> | can't quite place the new look; you went from Texas Ranger to something 70s I think |
| 10:26 | <MikeSmith> | It's a temporary state while I transform into my next manifestation of the Buddha |
| 10:27 | <annevk> | Buddha is a worthy goal |
| 10:28 | <MikeSmith> | Bodhisattva |
| 10:29 | <MikeSmith> | but the bodhisattva look is basically androgynous |
| 10:29 | <MikeSmith> | but I guess I'm too old to attempt that |
| 10:30 | <MikeSmith> | it is appealing though |
| 10:30 | <MikeSmith> | e.g., http://www.tibetanart.us/art/bodhisattva.jpg |
| 10:30 | <annevk> | it seems you might need a stache for that: http://en.wikipedia.org/wiki/File:Siddhartha.jpg |
| 10:30 | <MikeSmith> | excellent |
| 10:30 | <MikeSmith> | we're making progress |
| 10:31 | <MikeSmith> | Bodhisattva with a beer gut |
| 10:31 | <MikeSmith> | I could probably pull that one off |
| 10:33 | MikeSmith | gets to the point in webkit-dev archive where "Turning on MathML by Default?" thread took place |
| 10:33 | <MikeSmith> | thread seems to have died without resolution |
| 10:34 | <othermaciej> | I need a new look too |
| 10:34 | <MikeSmith> | maybe othermaciej could chime in on it |
| 10:34 | <othermaciej> | maybe I should grow a moustache |
| 10:34 | <MikeSmith> | othermaciej: I think I saw a picture of you a while back where you had bleached-blonde hair |
| 10:34 | <MikeSmith> | or highlighted or something at least |
| 10:35 | <MikeSmith> | othermaciej: if you grow a mustache, I'll grow mine back to |
| 10:35 | <MikeSmith> | *too |
| 10:35 | <othermaciej> | I have had long black hair, short bleached hair, short hair with high-contrast highlights, red hair... |
| 10:35 | <annevk> | searching on G for moustache yields: http://to55er.files.wordpress.com/2009/11/moustache-2.jpg |
| 10:35 | <othermaciej> | MikeSmith: the problem is when I try to grow one it ooks like a sleazy porno-stache |
| 10:35 | <MikeSmith> | othermaciej: that's the goal |
| 10:36 | <MikeSmith> | that's pretty much how mine looked |
| 10:36 | <MikeSmith> | that's the pinnacle of mustache looks |
| 10:36 | <MikeSmith> | not everybody can do the pornstache |
| 10:36 | <MikeSmith> | annevk: that dude's like Yosemite Sam with a bad creative consultant |
| 10:39 | <MikeSmith> | cool to see possible implementation work on context menus starting |
| 10:41 | <annevk> | in webkit? |
| 10:42 | <MikeSmith> | yeah |
| 10:42 | <volkmar> | annevk: for the form attribute email, i'm not wondering if i have to follow line by line what is described but why the description look much more like implementations details |
| 10:42 | <MikeSmith> | annevk: https://lists.webkit.org/pipermail/webkit-dev/2010-April/012604.html |
| 10:42 | <MikeSmith> | message from Drew Wilson at Google |
| 10:44 | <MikeSmith> | I wonder how practical it might be to try to put together a graph of some kind to track browser implementation status for HTML5 features |
| 10:46 | <MikeSmith> | annevk: btw, did you make any progress on getting the splitter to generate files per-H3 or whatever? (to make the filenames in URLs more relevant) |
| 10:46 | <annevk> | volkmar, the requirements seem relevant to me, but okay |
| 10:47 | <annevk> | MikeSmith, yeah, need surprisingly few changes |
| 10:47 | <MikeSmith> | ah, great |
| 10:47 | <MikeSmith> | what's the URL again? |
| 10:47 | <MikeSmith> | for the multipage complete spec |
| 10:47 | <annevk> | http://www.whatwg.org/specs/web-apps/current-work/complete/ or http://html5.org/complete/ |
| 10:47 | MikeSmith | looks |
| 10:47 | <annevk> | do you want to know how to modify spec-splitter.py? |
| 10:48 | <MikeSmith> | ah, this is great |
| 10:48 | <MikeSmith> | annevk: yeah, I would like to have the W3C version do the same |
| 10:50 | <annevk> | so in the functions should_split(e) and get_heading_text_and_id(e) |
| 10:50 | <annevk> | you want to replace the lines that start with if e.tag == 'div' simply with if e.tag == 'div': |
| 10:51 | <annevk> | so that it no longer does the and operator |
| 10:51 | <annevk> | then you modify split_exceptions with all the additional splits you want to make |
| 10:52 | <annevk> | i'll put my copy somewhere |
| 10:53 | <annevk> | http://html5.org/temp/2010/spec-splitter.txt |
| 10:53 | <MikeSmith> | annevk: thanks |
| 10:54 | <annevk> | (but that's all the changes I made iirc) |
| 10:54 | MikeSmith | goes to hack the w3c splitter copy |
| 10:56 | <MikeSmith> | annevk: hmm, I also see differences in the value of split_exceptions |
| 10:56 | <MikeSmith> | did you change that too? |
| 10:56 | <MikeSmith> | or maybe my copy is older than what you started with from upstream |
| 10:56 | <annevk> | yeah, I added exceptions |
| 10:56 | <MikeSmith> | ah, OK |
| 10:57 | <annevk> | to make splits for websockets et al better |
| 10:57 | <annevk> | since you don't have complete you might not need all of them |
| 10:57 | <MikeSmith> | hai |
| 11:08 | <MikeSmith> | annevk: thanks -- I think it worked |
| 11:08 | <MikeSmith> | http://dev.w3.org/html5/spec/ |
| 11:16 | <Philip`> | Someone should update the copy in the html5 project SVN if there's changes that ought to be used everywhere |
| 11:18 | <annevk> | I guess removing the check whether the div has a class of impl in the two functions should be changed everywhere as it breaks certain functionality of split_exceptions |
| 11:34 | <MikeSmith> | which part of http://dev.w3.org/html5/spec/association-of-controls-and-forms.html#association-of-controls-and-forms is about nested forms? |
| 11:34 | MikeSmith | is looking at http://lists.w3.org/Archives/Public/public-html-bugzilla/2010May/0342.html |
| 11:40 | <MikeSmith> | ah cool -- <progress> actually works in Chrome and Safari now |
| 11:41 | <MikeSmith> | I guess that's probably old new.. I reckon I'm close to a month or more behind on things |
| 11:42 | <MikeSmith> | *news |
| 11:45 | <MikeSmith> | does anybody have a demo page for <progress> ? |
| 11:51 | <Dashiva> | MikeSmith: Nested forms are removed in the parser |
| 11:52 | <MikeSmith> | Dashiva: I see |
| 11:52 | <Dashiva> | <form> a <form> b </form> c </form> becomes <form> a b </form> c |
| 11:53 | <MikeSmith> | OK |
| 11:54 | <MikeSmith> | so I guess the bug commenter wants that to be made more explicit |
| 11:54 | <MikeSmith> | or something |
| 11:54 | MikeSmith | finds http://trac.webkit.org/export/59461/trunk/LayoutTests/fast/dom/HTMLProgressElement/progress-element.html |
| 11:58 | <Dashiva> | MikeSmith: I guess, although the form element does specify content model: no form children |
| 11:58 | <MikeSmith> | yeah |
| 11:58 | <annevk> | via reader recommended: http://www.reddit.com/r/funny/comments/c33my/on_their_way_to_getting_married_a_young_couple_is/ lol |
| 12:26 | <hsivonen> | Which part of the spec covers handling this in a Web-compatible way: https://bug565432.bugzilla.mozilla.org/attachment.cgi?id=445028 ? |
| 12:31 | <annevk> | what is the bug hsivonen? URL parsing? |
| 12:31 | <hsivonen> | annevk: failure to remove leading whitespace in the ftp case |
| 12:32 | <annevk> | I believe leading and trailing whitespace is to be trimmed for all URLs |
| 12:32 | <annevk> | though not by the HTML parser, of course |
| 12:33 | <hsivonen> | annevk: is this in a spec that got moved to the IETF to die? |
| 12:34 | <annevk> | right |
| 12:34 | hsivonen | is a bit annoyed at failing to find an algorithm by following hyperlinks in the HTML5 spec |
| 12:34 | <annevk> | blame LM |
| 12:34 | <Dashiva> | "The href attribute on a and area elements must have a value that is a valid URL potentially surrounded by spaces. This URL is the destination resource of the hyperlink." |
| 12:34 | <Dashiva> | Doesn't that cover it? |
| 12:35 | <Dashiva> | or is that just author conformance, maybe |
| 12:35 | <annevk> | he thought it would better if HTML5 didn't reference the old splitted out thing from DanC anymore |
| 12:35 | <annevk> | Dashiva, that's authoring conformance |
| 12:35 | <annevk> | Dashiva, you want the part about resolving which reference parsing, etc. |
| 12:36 | <Dashiva> | Oh, right. That split. |
| 12:40 | <hsivonen> | well, this is odd. by code inspection, Gecko seems to do the same thing for both http: and ftp: already... |
| 14:29 | <hsivonen> | Larry Masinter's response on http://www.w3.org/2002/09/wbs/40318/issue-90-objection-poll/results is interesting |
| 14:29 | <hsivonen> | "Without a clear, acceptable transition plan, the risk is to fragment the web, and to encourage authors to create "best viewed by HTML5" web sites, in a repeat of Browser Wars 1.0." |
| 14:30 | <Dashiva> | hsivonen: Interesting... as in demonstrating he isn't even trying to understand? |
| 14:34 | <Lachy> | wow. Clearly, he isn't aware of all the effort that went into figuring out how to make these new elements degrade in older browsers |
| 14:35 | <Lachy> | especially in IE, and the base html5 CSS that a few people have made to give sensible defaults |
| 23:05 | <AryehGregor> | I wonder if anyone can come up with a response to this guy's signature: http://mobile.slashdot.org/comments.pl?sid=1652454&cid=32208264 |
| 23:05 | <AryehGregor> | It seems like it would be pretty easy to do that in HTML5 if you had the original assets. |
| 23:05 | <AryehGregor> | (I mean, like actually porting Badger Badger to HTML5) |
| 23:05 | <AryehGregor> | . . . Probably not worth the effort. |
| 23:07 | <othermaciej> | I don't see a signature on that post |
| 23:07 | <mbrubeck> | I had to log in and turn off "Disable sigs" |
| 23:07 | <mbrubeck> | it's "Want to replace Flash with HTML5? First try porting Badgers." |
| 23:08 | <Dashiva> | At some point I'm sure someone will make a scene library of sorts to emulate basic flash animations |
| 23:08 | <AryehGregor> | With a link: http://www.badgerbadgerbadger.com/ |
| 23:09 | <AryehGregor> | I'm surprised Slashdot signatures are disabled by default. The length limit means that they're by far the best signatures I've seen on any website. |
| 23:09 | <AryehGregor> | People only have room for a tiny bit of info, so they make it pithy or informative. |
| 23:09 | <AryehGregor> | One of my favorites goes something like: "I would have made this post shorter, but I didn't have the time." |
| 23:09 | <Dashiva> | Pssh, I'm on a forum with max 15 characters :P |
