| 00:23 | <Philip`> | Is it just me that finds it annoying how the multi-page spec's next/previous page links try to jump down to skip the header on the subsequent page (and get it wrong half the time because the page is small enough to fit on the screen without scrolling, so it jumps up and down as you navigate around)? |
| 00:33 | <SpookyET_> | Firefox needs fcgi/scgi for extensions. It needs persistent extensions. |
| 08:23 | <krijnh> | Hixie: why do you use <!DOCTYPE HTML5> for your tests? |
| 08:25 | <Philip`> | Because everybody loves versioning |
| 08:25 | <krijnh> | Ow, never mind |
| 08:25 | <krijnh> | 'Those are just old tests. Shouldn't make any difference.' |
| 08:25 | <krijnh> | :) |
| 08:26 | <annevk> | does make a difference though |
| 08:26 | <Philip`> | Not having a version number would just be unnatural and unthinkable |
| 08:26 | <annevk> | but the difference is likely not to be relevant for the tests in question |
| 08:26 | <krijnh> | Only gives quirks mode in Gecko |
| 08:26 | <krijnh> | Nope |
| 08:26 | <krijnh> | But I was just wondering |
| 08:37 | krijnh | cleans house with the Cleaning House thread |
| 08:39 | <Philip`> | You can play ping pong with it too |
| 08:39 | <krijnh> | :) |
| 08:41 | <Philip`> | I expect some of these thread titles will be hard to find again in the future, but I expect that wouldn't matter since people won't actually want to find them |
| 08:41 | <krijnh> | Which reminds me |
| 08:41 | <krijnh> | Somebody wanted a search box on /irc-logs/ |
| 08:42 | <marcosc> | krijnh, that could lead to trouble! :D |
| 08:42 | <krijnh> | marcosc: why? |
| 08:42 | <krijnh> | You can already search with site: now |
| 08:43 | <marcosc> | More people would look themselves up to see what we on IRC have been saying about them... oh, I didn't know you could search the site already |
| 08:43 | <marcosc> | :) |
| 08:43 | marcosc | only joking |
| 08:43 | <krijnh> | :) |
| 08:43 | <krijnh> | Only annevk is making fun of people anyway ;) |
| 08:43 | <marcosc> | LOL |
| 08:51 | <krijnh> | http://krijnhoetmer.nl/irc-logs/#search |
| 08:53 | marcosc | searches for himself to see what defamatory things Annevk has been saying about him. |
| 09:10 | <annevk> | about you? |
| 09:10 | <annevk> | nothing in public |
| 09:14 | <krijnh> | :) |
| 09:15 | <krijnh> | Yay, ads |
| 09:15 | <annevk> | ads? |
| 09:15 | <annevk> | are you now making profit on my poetry here? |
| 09:15 | <krijnh> | Nope |
| 09:15 | <krijnh> | Only on the index page |
| 09:15 | <krijnh> | Which doesn't make sense at all |
| 09:15 | <krijnh> | Cause there's no content there |
| 09:16 | annevk | doesn't see them |
| 09:17 | <krijnh> | Me neither |
| 09:17 | <krijnh> | Blocked content hooray |
| 09:17 | zcorpan | sees them now |
| 09:18 | krijnh | never noticed Google ads a colon to <dt> elements.. |
| 09:18 | <krijnh> | adds even |
| 09:19 | <Philip`> | I believe putting Google ads on pages without content is against their TOS, and they'll ban the account if they notice |
| 09:19 | <krijnh> | There is content |
| 09:20 | <krijnh> | But you mean I should put it on the subpages? :) |
| 09:20 | <Philip`> | Not on that page - it's just a list of dates and refer(r)ers :-) |
| 09:20 | <krijnh> | I'll fix some content there for you then :) |
| 09:21 | <Philip`> | (There were problems with using Google ads on some forums I've been involved with - most of the pages there don't count as content-based, so you have to remove the ads from them) |
| 09:22 | <krijnh> | There |
| 09:24 | <Philip`> | Any chance of doing Punycode conversion in the referrers list? :-) |
| 09:24 | <krijnh> | Punycode? |
| 09:24 | krijnh | reads up |
| 09:24 | <Philip`> | Like with http://xn--74h.damowmow.com/ |
| 09:25 | <Philip`> | Hmm, Opera converts that into a happy face but Firefox is sad and doesn't |
| 09:25 | <zcorpan> | ☺ |
| 09:25 | annevk | mostly uses http://damowmow.com/portal/ |
| 09:25 | <krijnh> | So why do we see xn--74h ? |
| 09:28 | <zcorpan> | krijnh: it's the punycode for ☺ (decode this as utf-8) |
| 09:28 | <Philip`> | xn--74h is just Punycode's spelling of that Unicode character, so it doesn't break people that expect a limited character set in domain names |
| 09:29 | <Philip`> | What'd be really neat is to register a domain name that spells some sensible Unicode word, where its Punycode encoding also spells a sensible ASCII word... |
| 09:30 | <annevk> | except for the xn-- bit? |
| 09:30 | <zcorpan> | http://www.ietf.org/rfc/rfc3987.txt |
| 09:30 | <annevk> | i don't think that's the spec for idna zcorpan |
| 09:30 | <annevk> | or was it idn |
| 09:31 | <annevk> | www.ietf.org/rfc/rfc3490 |
| 09:31 | <annevk> | http://www.ietf.org/rfc/rfc3490 |
| 09:31 | <Philip`> | http://tools.ietf.org/html/rfc3492 |
| 09:51 | <peepo> | annevk what's with w3 validator? |
| 09:55 | <annevk> | I'm the wrong person to ask, really |
| 09:56 | <mikeday> | Is anyone working on a HTML5 parsing library at the present time? |
| 09:57 | <jgraham_> | code.google.com/p/html5lib/ |
| 09:57 | <jgraham_> | That's python. Also gsnedders is working on PHP I think |
| 09:57 | <mikeday> | How about C? :) |
| 09:57 | <jgraham_> | mikeday: Not taken. Go for it ;) |
| 09:58 | <annevk> | mikeday, please :) |
| 09:58 | <mikeday> | Presumably, the Mozilla parser is already a C++ implementation, or partial implementation? |
| 09:58 | <mikeday> | Hi Anne :) |
| 09:58 | <annevk> | it doesn't do HTML5 though |
| 09:58 | <annevk> | starting from WebKit might be your best bet |
| 09:59 | <annevk> | if you don't want to do it from scratch |
| 09:59 | jgraham_ | wants an implementation in Gecko |
| 09:59 | <mikeday> | WebKit also C++, right? Simpler code than Mozilla? |
| 09:59 | annevk | doesn't know how well you can extract that piece of code out of the rest though |
| 09:59 | <mikeday> | It's amazing that there is still no browser-compatible parser outside of the browsers themselves. |
| 10:00 | <annevk> | mikeday, it certainly looks simpler to me, it also implements something far close to what HTML5 wants out of <b> <i> </b> |
| 10:00 | <mikeday> | ah, well that's good. |
| 10:00 | <annevk> | html5lib is pretty close, but it's not really fast |
| 10:00 | <mikeday> | What about starting with html5lib, and writing a C parser based on that? |
| 10:01 | <annevk> | that's my plan, but I've had that plan for almost half a year now... |
| 10:01 | <Philip`> | Is it easier to start with html5lib than to start with the spec? |
| 10:01 | <hsivonen> | my plan is to get Java covered Real Soon New |
| 10:01 | <hsivonen> | Now |
| 10:02 | <annevk> | html5lib can show you some implementation ideas |
| 10:02 | <hsivonen> | mikeday: the Gecko HTML parser is not an HTML5 parser |
| 10:02 | <mikeday> | Is the spec complete enough to fully implement a parser for the web as it stands? |
| 10:02 | <annevk> | but apart from that the spec should be fine |
| 10:02 | <Philip`> | Someone should just write it a language-agnostic format that can be transformed into source code for whatever language you're using |
| 10:02 | <hsivonen> | mikeday: you probably don't want to get near the Gecko HTML parser anyway |
| 10:02 | <annevk> | mikeday, we hope so :) |
| 10:02 | <mikeday> | Philip, right. |
| 10:02 | <annevk> | mikeday, but it probably needs some further tweaking in due course |
| 10:02 | Philip` | has absolutely no idea how you'd do that |
| 10:03 | <mikeday> | One more question, as I'm still not entirely clear on this |
| 10:03 | <annevk> | Philip`, is that the "formal language" idea? |
| 10:03 | <mikeday> | will a parser written to the HTML5 spec break on existing websites? |
| 10:03 | <annevk> | it should not |
| 10:03 | <mikeday> | ie. will it result in a substantially different DOM than currently generated by browsers? |
| 10:03 | <annevk> | it should not |
| 10:03 | <Philip`> | annevk: Possibly - not really formal in a mathematical sense, but at least machine-processable rather than English |
| 10:03 | <mikeday> | Oh, well, that's good; only need one parser instead of two, then :) |
| 10:03 | <annevk> | you need two |
| 10:03 | <hsivonen> | Philip`: you could make compilers for a language that target other HLLs. but the result would suck in terms of getting buffering and language-specific APIs right |
| 10:03 | <annevk> | XML and HTML |
| 10:03 | <mikeday> | hah |
| 10:04 | <mikeday> | XML and HTML, that's fine. |
| 10:04 | <annevk> | good :) |
| 10:04 | <mikeday> | Just don't want HTML and HTML5 separately :) |
| 10:04 | <annevk> | join the HTML WG and say so :) |
| 10:04 | <annevk> | although i think the charter says so too so it should be fine |
| 10:04 | <hsivonen> | Philip`: for example, I intend to make a serious effort to get the buffering performance with Java and SAX right |
| 10:04 | <mikeday> | hmm, I don't think the HTML WG is suffering from a lack of people, right now :) |
| 10:04 | <annevk> | :p |
| 10:05 | <mikeday> | hey annevk, were you in Australia recently? |
| 10:05 | <annevk> | yeah |
| 10:05 | <annevk> | in Brisbane |
| 10:05 | <mikeday> | ah, didn't come down to Melbourne then. Next time hmm? :) |
| 10:05 | <annevk> | yeah, maybe |
| 10:05 | <annevk> | i'd like to come back although the trip is quite long |
| 10:05 | <mikeday> | Indeed it is |
| 10:06 | <annevk> | will you be at XTech? |
| 10:06 | <mikeday> | 'fraid not this time, too busy trying to get Prince 6.0 out :) |
| 10:06 | <annevk> | ah, have fun with that then :) |
| 10:07 | <mikeday> | thanks! :) |
| 10:08 | <mikeday> | gee, there is a lot of prose in the syntax portion of the HTML5 spec |
| 10:08 | <mikeday> | can I say +1 to formal language |
| 10:09 | <hsivonen> | mikeday: which one? C? Java? Sawzall? Python? :-) |
| 10:10 | <mikeday> | hmm, and parsing is interspersed with script execution; so much for layering. Not exactly HTML5's fault, though :) |
| 10:10 | <mikeday> | hsivonen: BNF? :) |
| 10:11 | <Philip`> | Can BNF do error handling? |
| 10:11 | <hsivonen> | Philip`: I was about to ask that |
| 10:11 | <mikeday> | on the other hand, there is a state machine |
| 10:12 | <hsivonen> | btw, has anyone found non-stack-like state transitions in the tokenizer, yet? |
| 10:12 | hsivonen | intends to keep the state implicitly on the runtime stack and use a ReprocessInDataStateException for abtrupt returns |
| 10:13 | <annevk> | entities are non state like |
| 10:13 | <annevk> | they are more like a function |
| 10:14 | <mikeday> | hsivonen: can you use an array-based DFA or similar rather than function calls? |
| 10:14 | <annevk> | and doctypes are slightly different too as they require you to consume several characters and such |
| 10:17 | <Philip`> | I think I remembering reading that the ANTLR 3 parser generator generates JVM bytecode so it can use goto for state transitions instead of function calls (though I've probably got all the details wrong now) |
| 10:18 | <mikeday> | Why not nextState = stateTable[currState][currChar]; ? |
| 10:19 | <Philip`> | That seems a bit inefficient when you've got 2^16 characters :-) |
| 10:19 | <mikeday> | I don't recall HTML assigning special meaning to any but the first 128 of them :) |
| 10:20 | <annevk> | heh, it would suggest you study the spec a bit closer |
| 10:21 | <mikeday> | damn. |
| 10:21 | <Philip`> | The HTML5 parser has a lot more discrete states than it explicitly mentions, if you count things like the PCDATA/CDATA/RCDATA/PLAINTEXT variable as giving four times as many potential states |
| 10:22 | mikeday | reads the spec |
| 10:23 | <Philip`> | Make sure you read it in all three directions :-) |
| 10:23 | <annevk> | lol |
| 10:23 | <Philip`> | (Not that I've ever bothered doing that) |
| 10:25 | <mikeday> | line 32942 has an unescaped < character |
| 10:25 | <mikeday> | as does line 32947 |
| 10:26 | <mikeday> | running it through Prince produces a 550 page PDF file |
| 10:26 | <mikeday> | but the page margins are too big, so that's not really a fair page count |
| 10:26 | <mikeday> | either way, might take me a while to get through it |
| 10:26 | <mikeday> | the question is, can I read it faster than people update it? |
| 10:26 | <annevk> | you don't need to read the whole HTML5 spec |
| 10:27 | <Philip`> | http://hsivonen.iki.fi/printing-wa10/ might be useful |
| 10:28 | <annevk> | http://www.whatwg.org/specs/web-apps/current-work/multipage/section-parsing.html |
| 10:28 | <annevk> | http://www.whatwg.org/specs/web-apps/current-work/multipage/section-tokenisation.html |
| 10:28 | <annevk> | http://www.whatwg.org/specs/web-apps/current-work/multipage/section-tree-construction.html |
| 10:28 | <annevk> | is all you need |
| 10:28 | <mikeday> | at least the prose should be marginally more understandable than the Mozilla codebase, right? :) |
| 10:29 | <annevk> | i was able to implement (together with jgraham_ and others) the thing in Python based on prose |
| 10:30 | <mikeday> | sounds like a challenge :) |
| 10:30 | <hsivonen> | mikeday: I hadn't thought of an array-based DFA |
| 10:31 | <annevk> | unrelated: something with opinions on execCommand()? execCommand('indent') for instance produces <blockquote> in IE |
| 10:31 | <annevk> | we copied that |
| 10:31 | <hsivonen> | mikeday: the spec is more understandable than Mozilla, yes. and Mozilla doesn't even implement the spec, yet. |
| 10:31 | <annevk> | mozilla puts a margin-left:40px on the element |
| 10:31 | <annevk> | same for things like the 'italic' and 'bold' commands |
| 10:31 | <mikeday> | hsivonen: Mozilla being out of sync with the spec could be seen as a defect in the spec... |
| 10:31 | <annevk> | differences all over |
| 10:31 | <hsivonen> | annevk: I prefer IE behavior there |
| 10:32 | <annevk> | hsivonen, also 'italic' -> <em>, 'bold' -> <strong>? |
| 10:32 | <hsivonen> | annevk: no, <i> and <b> |
| 10:32 | <hsivonen> | annevk: Safari is probably worse |
| 10:32 | <annevk> | mikeday, Mozilla has some really weird quirks |
| 10:32 | <annevk> | hsivonen, Safari actually does <i> and <b> |
| 10:32 | <mikeday> | annevk, are they consistent with IE's weird quirks, or unique to Mozilla? |
| 10:33 | <hsivonen> | mikeday: Gecko's HTML parsing is really, really weird in rather pointless ways. the spec most closely resembles WebKit |
| 10:33 | <annevk> | mikeday, unique to Mozilla |
| 10:33 | <mikeday> | ah, okay then. |
| 10:33 | <annevk> | the spec is closer to webkit / ie I think |
| 10:34 | <annevk> | minus the crasher from webkit :) |
| 10:34 | <mikeday> | annevk, roughly how long did it take to get html5lib working? |
| 10:35 | <annevk> | we didn't work on it fulltime |
| 10:35 | <annevk> | but in a week we had something working iirc |
| 10:36 | <annevk> | hsivonen, care to elaborate on why you prefer <blockquote>? |
| 10:36 | annevk | doesn't care |
| 10:36 | <annevk> | we got at least one complain though |
| 10:36 | <annevk> | on http://www.quirksmode.org/dom/execCommand.html |
| 10:36 | <hsivonen> | annevk: it is more tractable to CMSs that do not want to dive into CSS |
| 10:36 | <hsivonen> | annevk: I'd prefer <indent>, but it has to be called <blockquote> for compat |
| 10:37 | <hsivonen> | annevk: if you are writing a CMS and want to use a browser-based editor, Gecko and WebKit emitting style='' aren't helping at all |
| 10:38 | <annevk> | fair point |
| 10:38 | <hsivonen> | annevk: are those who complain CMS vendors or armchair semanticists? |
| 10:39 | <hsivonen> | oh. it was PPK! |
| 10:39 | hsivonen | didn't read right at first |
| 10:40 | <hsivonen> | Gecko, WebKit and Presto would do well if they didn't introduce gratuitous deviations from Trident for execCommand |
| 10:41 | <annevk> | but <strong> versus <b> is ok? |
| 10:41 | <annevk> | i suppose |
| 10:41 | <hsivonen> | annevk: it is pointless but easily normalized to either one in the CMS |
| 10:42 | <annevk> | some CMS vendors wanted <em> and <strong> because it was more semantic |
| 10:43 | <hsivonen> | those vendors have to semanticize the stuff they receive from Trident anyway |
| 10:44 | <annevk> | Trident gives you <em> and <strong> |
| 10:44 | <hsivonen> | ooh. |
| 10:45 | <hsivonen> | well, <em> and <strong> it is, then |
| 10:45 | <hsivonen> | more nails to the coffin |
| 10:46 | <hsivonen> | (of the de jure semantics of <em> and <strong>) |
| 10:46 | <annevk> | oh yeha |
| 10:46 | <annevk> | people don't understand half how "bad" the situation is |
| 10:54 | <zcorpan> | seems like toolman doesn't care if the spec is useful to anyone, he just doesn't want the de jure semantics of elements to change |
| 10:59 | <annevk> | use HTML4? |
| 10:59 | <annevk> | languages evolve, deal with it |
| 10:59 | <annevk> | is what i'd say |
| 11:13 | <Dashiva> | Who is this toolman? |
| 11:13 | <Hemebond> | Is it the improvetheweb.com guy? |
| 11:15 | <zcorpan> | http://www.autisticcuckoo.net/ |
| 11:19 | <Hemebond> | Oh yeah. That's the one I was thinking of. |
| 11:20 | <Hemebond> | I'm with him on most points I think. From what I can remember of the post. |
| 11:22 | <zcorpan> | Hemebond: can you elaborate on what the benefit is to retain the old de jure semantics even when it doesn't match the real world? |
| 11:24 | <mikeday> | do browsers have to care about semantics? or only editors? |
| 11:24 | <annevk> | browsers have to care about <a> for instance |
| 11:24 | <annevk> | and browsers support some type of editing: contenteditable and designMode |
| 11:24 | <zcorpan> | mikeday: markup consumers |
| 11:24 | <zcorpan> | not just browsers |
| 11:25 | <mikeday> | annevk, right, but eg. <em> vs. <i> |
| 11:25 | <mikeday> | or <i> vs <span> for that matter |
| 11:25 | <mikeday> | zcorpan, eg. google? |
| 11:25 | <zcorpan> | mikeday: yes |
| 11:25 | <zcorpan> | mikeday: browsers probably want to mark <i> and <em> different from the surrounding text in some way |
| 11:26 | <zcorpan> | e.g. italics or inverted colors or in speech in a different tone |
| 11:26 | <zcorpan> | while treat <span> the same as surrounding text |
| 11:27 | <mikeday> | right. |
| 11:27 | <mikeday> | em, i { font-style: italic } |
| 11:27 | <zcorpan> | yeah |
| 11:27 | <zcorpan> | for visual browsers |
| 11:27 | <mikeday> | but that treats both elements *identically* |
| 11:27 | <zcorpan> | mikeday: yes |
| 11:27 | <mikeday> | I guess what I'm getting at, is that a lot of time is spent discussing semantics of elements for the spec |
| 11:28 | <zcorpan> | indeed |
| 11:28 | <mikeday> | when in practice, the semantics end up getting decided after the fact, by informal agreement amongst users and implementors |
| 11:28 | <zcorpan> | indeed |
| 11:28 | <zcorpan> | what the spec says doesn't change the real world |
| 11:28 | <zcorpan> | it can either reflect the real world or be irrelevant |
| 11:28 | <mikeday> | descriptive vs. prescriptive, ie. HTML is like an extension of natural language |
| 11:29 | <mikeday> | or informal markup conventions, eg. smileys :) :( |
| 11:29 | <mikeday> | a "spec" for smileys would not be useful; a "guide" to smileys would be more appropriate |
| 11:30 | <mikeday> | or are :) and ^_^ actually just different syntactic forms for the same underlying DOM... |
| 11:30 | <zcorpan> | @_@ |
| 11:31 | <mikeday> | if the amount of effort spent on <i> and <em> semantics had been spent defining *table* semantics |
| 11:31 | <mikeday> | well, that would be good. |
| 11:33 | <zcorpan> | tables is another thing |
| 11:33 | <zcorpan> | screen readers have to figure out when a table is used for layout and when it is used for data |
| 11:33 | <mikeday> | to be honest, I really mean table rendering rather than semantics |
| 11:33 | <zcorpan> | ah |
| 11:33 | <zcorpan> | ok |
| 11:33 | <mikeday> | but given that tables are used 90% of the time to achieve a visual effect, that seems reasonable |
| 11:35 | <zcorpan> | not sure if it's worth figuring out what screen readers do and then define an algorithm for the purpose of determinating whether a <table> is used for layout or data |
| 11:35 | <zcorpan> | probably an area where screen readers can compete on being useful |
| 11:40 | <annevk> | Does anyone happen to know if HTML5 now accurately describes how <body onload=> versus window.onload etc. defines? |
| 11:46 | <annevk> | s/defines/works/ |
| 11:46 | <annevk> | doesn't look like it |
| 12:17 | <hsivonen> | I wonder if I'm too offensive with a bullet point that says "anyURI is a joke" |
| 12:18 | <annevk> | it would make you funny |
| 12:18 | <annevk> | not offensive |
| 12:18 | <hsivonen> | annevk: as in people laughing at me or as in people laughing at anyURI? |
| 12:19 | <hsivonen> | anyURI is just so mind-boggingly badly specced |
| 12:19 | <annevk> | at anyURI and to you |
| 12:19 | <annevk> | (as opposed to "at you") |
| 12:19 | <hsivonen> | ok |
| 12:21 | <mikeday> | is anyURI an XSD schema thing? |
| 12:21 | <hsivonen> | mikeday: yes |
| 12:22 | <hsivonen> | mikeday: the definition has always been foggy and it has changed with every spec revision. eventually they conceded that any finite string is a valid anyURI |
| 12:22 | <hsivonen> | really useful indeed |
| 12:22 | mikeday | grins |
| 12:22 | <mikeday> | at least URIs of infinite length are ruled out :) |
| 12:23 | <mikeday> | I find file:// URLs the most annoying, personally |
| 12:24 | annevk | finds most URLs annoying |
| 12:24 | annevk | tries not to deal with them |
| 12:24 | <annevk> | Actually, I rather like data: URIs except that it should be made more clear what # does |
| 12:25 | <mikeday> | annevk works on the web, annevk tries not to deal with URLs |
| 12:25 | <mikeday> | amazing annevk's head has not yet exploded :) |
| 12:26 | <mikeday> | (I quite agree though, URLs suck) |
| 12:26 | <Hemebond> | URLs suck? |
| 12:27 | <mikeday> | suck == poorly specified |
| 12:27 | <Hemebond> | oh |
| 12:27 | <mikeday> | not UNICODE-aware |
| 12:28 | <annevk> | they are sort of UNICODE aware |
| 12:28 | <mikeday> | and stupid syntax |
| 12:28 | <annevk> | but the specs don't match the implementations |
| 12:28 | <annevk> | it's a big mess |
| 12:28 | <annevk> | and the people who once made it all happen don't clean it up |
| 12:29 | <annevk> | (see also HTTP, CSS, DOM, XML and several other specs) |
| 12:29 | <annevk> | well, CSS is still being cleaned up |
| 12:29 | <annevk> | to be fair |
| 12:29 | <mikeday> | I still find it amazing sometimes, that the fundamental tech. of our time is so poorly worked out |
| 12:30 | <mikeday> | XML is fairly clean these days, if you ignore its dependencies on URLs |
| 12:32 | <mikeday> | (XML not including XSD schema). |
| 12:32 | <annevk> | and not including DTDs? |
| 12:33 | <mikeday> | well, DTDs are *clean*, they're just *lame* |
| 12:34 | <mikeday> | but the spec defines what to do with them |
| 12:34 | <mikeday> | arguably parameter entities could be specified in a more thorough manner |
| 12:35 | <annevk> | yeah, fair enough |
| 12:35 | <mikeday> | obviously an XML 2.0 could make some improvements, but at least the XML 1.0 spec agrees with reality. |
| 12:36 | <annevk> | not with character encoding and non well-formedness on mobile content and such |
| 12:37 | <annevk> | and feeds |
| 12:37 | <hsivonen> | mikeday: the reality of how IDness is established doesn't always agree with specs |
| 12:37 | <mikeday> | feeds are not XML |
| 12:37 | <mikeday> | that's more a problem with RSS specs than XML spec |
| 12:38 | <mikeday> | hsivonen, right, which kind of situations though? |
| 12:38 | <hsivonen> | mikeday: DTDless XHTML for example |
| 12:39 | <mikeday> | DTDless XML of any kind has no ID attributes, except for xml:id |
| 12:39 | <hsivonen> | mikeday: you want to have a filter somewhere that makes id an ID |
| 12:39 | <hsivonen> | mikeday: that's exactly the kind of unrealism I am talking about |
| 12:40 | <hsivonen> | mikeday: fortunately, Prince works with reality here :-) |
| 12:40 | <mikeday> | hmm. Does it? :) |
| 12:40 | mikeday | checks Prince |
| 12:40 | <hsivonen> | mikeday: yes. document-internal links to ids work without a DTD |
| 12:40 | <mikeday> | ah. |
| 12:40 | <mikeday> | that's because we don't use XML IDness to determine links :) |
| 12:41 | <annevk> | Jonas Sicking proposed to make every id= attribute act as ID |
| 12:41 | annevk | likes that |
| 12:41 | mikeday | likes that too |
| 12:41 | <mikeday> | don't think it will fly, though. |
| 12:41 | <annevk> | and his argument is that we'd just be changing getElementById() and #id |
| 12:42 | <annevk> | not XML |
| 12:42 | <mikeday> | right |
| 12:42 | <annevk> | which could work in theory |
| 12:42 | <annevk> | if all browser vendors just implement it at some point a standard will catch up... |
| 12:42 | <hsivonen> | annevk: I think it should be defined an XHTML id processor between the XML processor and the app. (with a permission to implement differently if indistinguishable) |
| 12:43 | <annevk> | this is not just about XHTML |
| 12:43 | <hsivonen> | annevk: that's how I implement it concretetly, btw |
| 12:43 | <hsivonen> | annevk: well, an 'id processor' then |
| 12:44 | <annevk> | fair enough |
| 12:44 | <annevk> | and sure |
| 12:44 | <annevk> | as long as everything works as you'd expect I don't really care how it's defined |
| 12:44 | <mikeday> | must go |
| 12:44 | mikeday | waves |
| 12:44 | <hsivonen> | bye |
| 12:44 | <annevk> | bye |
| 12:48 | hsivonen | adds a slide about IDness |
| 12:52 | <annevk> | oh good |
| 12:52 | <annevk> | Acid3 doesn't test the very evil of implied <head> parsing |
| 12:52 | hsivonen | now has a slide titled "Future of IDness" |
| 12:54 | <annevk> | do you follow the Moz xml:id bug? |
| 12:54 | <hsivonen> | not actively |
| 12:54 | <hsivonen> | every four months or so :-) |
| 12:54 | <annevk> | https://bugzilla.mozilla.org/show_bug.cgi?id=275196 |
| 12:54 | <annevk> | same here |
| 12:54 | <annevk> | it doesn't change more often anyway |
| 12:59 | <hsivonen> | metooed what I just said here on the bug as well |
| 13:32 | <Dashiva> | annevk: What is the very evil? |
| 13:55 | <annevk> | </head><style></style><p> |
| 13:55 | <annevk> | where <style> ends up in <head> |
| 14:13 | <gsnedders> | annevk: well, I'm not really working on a PHP parser… too many exams :( |
| 14:13 | <annevk> | Huh? |
| 14:14 | <annevk> | This is the second time you say something to me I don't get :) |
| 14:14 | <annevk> | First OS X, now a PHP parser... |
| 14:14 | <gsnedders> | annevk: a PHP HTML5 parser… I have no time to work on it, so I'm not working on it :P |
| 14:14 | <annevk> | Sure, but did I ask about it? :) |
| 14:14 | <gsnedders> | you said I was working on one earlier :P |
| 14:15 | <Philip`> | http://krijnhoetmer.nl/irc-logs/whatwg/20070511#l-150 ? |
| 14:15 | gsnedders | can't read. |
| 14:15 | <annevk> | indeed |
| 14:15 | <annevk> | :) |
| 14:20 | <gsnedders> | zcorpan: you've missed translating one quote |
| 14:20 | <zcorpan_> | oops |
| 14:20 | <gsnedders> | zcorpan: "Webbläsare kan inte göra så mycket skoj med <p>. Oavsett vad specen säger att en <p> representerar." is meaningless to me :) |
| 14:58 | <annevk> | zcorpan, anything else that should be dropped? :) |
| 15:00 | <zcorpan> | annevk: don't think so |
| 15:00 | zcorpan | still needs to write those test cases he promised to do |
| 15:01 | <annevk> | yeah |
| 15:02 | <zcorpan> | perhaps text/xsl from the list of what is an XML MIME type, at least if ie doesn't treat it as such anyway |
| 15:03 | <annevk> | i suppose |
| 15:47 | hsivonen | realizes that SVG has unfortunate xml:id/id IDness interaction |
| 15:47 | <annevk> | SVG 1.2 has |
| 15:47 | <annevk> | but that's a non backwards compatible change |
| 15:48 | <annevk> | which seems badly informed |
| 15:49 | <hsivonen> | yeah. |
| 15:49 | <hsivonen> | any chance of getting it repealed? |
| 15:49 | <annevk> | dunno |
| 15:50 | <annevk> | i keep hoping |
| 15:50 | hsivonen | wonders whether he should write an "XML ID 5" spec |
| 15:50 | <annevk> | :) |
| 15:51 | <hsivonen> | annevk: have objections been filed against SVG 1.2 on this topic? |
| 15:51 | <annevk> | copy xml:id and s/xml:id/id/ plus some other minor fixes :) |
| 15:51 | <annevk> | I believe people did do that, yes |
| 15:51 | <annevk> | but maybe not clear enough |
| 15:51 | <annevk> | SVG also requires XML Events, Traits and other things |
| 15:54 | <hsivonen> | last night, I read slides from a WWW2007 slideshow that mentioned xml:id and XML Events as spinoffs of XHTML 2.0 |
| 15:54 | <othermaciej> | SVG 1.2 is full of silly things |
| 15:54 | <hsivonen> | othermaciej: which why I've been saying that SVG 1.1 is part of my long-term goals for the conformance checker |
| 15:56 | <othermaciej> | SVG 1.1 has some silly things too, like SVG fonts |
| 15:56 | <annevk> | I would love a revision of SVG in Hixie or equivalent style |
| 15:58 | <othermaciej> | SVG is huge |
| 15:59 | <othermaciej> | just the language I mean |
| 15:59 | <annevk> | Yeah |
| 15:59 | <annevk> | I'm trying to find a week to spend on learning more of SVG |
| 15:59 | <annevk> | I'm able to create rectangles, circles, gradients and all that, but there's so much more... |
| 16:00 | <hsivonen> | my SVG knowledge is not quite up to date. I studied the spec pre-1.0, because I wrote a magazine article about it back then |
| 16:01 | <hsivonen> | however, I've learned a thing or two about practical SVG when drawing the figures for my thesis |
| 16:02 | <hsivonen> | annevk: for example, Opera 9.20 does not seem to treat viewBox as the intrinsic aspect ratio of <svg>, which sucks |
| 16:02 | <hsivonen> | and Prince seems to calculate height percentages differently from Gecko, WebKit and Presto |
| 16:02 | <annevk> | SVG always has an intrinsic height and width I think so I'm not sure what that would do |
| 16:03 | <annevk> | (Although that depends on who you ask. Some will say that percentage widths are in fact not intrinsic widths.) |
| 16:04 | <hsivonen> | annevk: for practical purposes, it should be easy and possible to say that I want the <svg> element to have a width set by me and the UA to compute the height of the box so that the aspect ratio of viewBox is preserved |
| 16:04 | <hsivonen> | this doesn't just work |
| 16:04 | <hsivonen> | which suck big time |
| 16:04 | <hsivonen> | sucks |
| 16:04 | <nickshanks> | it works for me |
| 16:04 | <annevk> | yeah, height= defaults to 100%... |
| 16:04 | <nickshanks> | set viewBox and width, but leave height off |
| 16:04 | <annevk> | (and width= too, for that matter) |
| 16:04 | <hsivonen> | nickshanks: works for you across Gecko, Presto, WebKit and Prince? good for you |
| 16:05 | <nickshanks> | well, I only tried with WebKit and the wikipedia svg2png rasteriser |
| 16:05 | <annevk> | although I suppose a height of a 100% might make the intrinsic height ignored in case of an auto or percentage height parent in which case you would use the aspect ratio... |
| 16:05 | <hsivonen> | also, I learned that the SVG export of OmniGraffle Pro sucks big time |
| 16:05 | <annevk> | but that's a guess |
| 16:06 | <nickshanks> | i have OmniG. Pro, can test if you want |
| 16:06 | <hsivonen> | Illustrator CS2 with text converted to path gives the best visual fidelity for PDF conversions |
| 16:06 | <hsivonen> | and Inkscape is the best for creating SVG where text is text (not paths) |
| 16:06 | <nickshanks> | nah, BBEdit is the best for that |
| 16:06 | <hsivonen> | all in all, not ready for J. Random illustrator :-( |
| 16:07 | <hsivonen> | nickshanks: I used a combo of Inkscape, TextWrangler and oXygen |
| 16:07 | <hsivonen> | again, not ready for "normal" people |
| 16:07 | <nickshanks> | i just use a text editor (sometimes BBEdit, sometimes TextMate) |
| 16:08 | <nickshanks> | but then i don't draw tigers |
| 16:08 | <hsivonen> | annevk: in Presto, WebKit and Gecko height='100%' is computed from the containing block height |
| 16:08 | <hsivonen> | annevk: in Prince from the containing block width |
| 16:09 | <hsivonen> | oh, and I learned that Presto and Prince don't support arrowheads |
| 16:09 | <hsivonen> | this needs to work much smoother to compete with Flash, PDF and Silverlight |
| 16:09 | <nickshanks> | does PDF have arrowheads? |
| 16:10 | <hsivonen> | nickshanks: I don't remember, but any decent PDF-outputting illustration program does |
| 16:10 | <nickshanks> | i've always just used triangles on the end of the line |
| 16:11 | <hsivonen> | nickshanks: manually placed? |
| 16:11 | <nickshanks> | yes |
| 16:11 | <hsivonen> | not fun |
| 16:11 | <annevk> | hsivonen, sure |
| 16:11 | <annevk> | hsivonen, I blame the spec |
| 16:12 | <nickshanks> | text in Presto is huge too |
| 16:12 | <hsivonen> | annevk: I want both CSS and SVG fixed so that reasonable use cases are easy |
| 16:12 | <annevk> | I would love to improve SVG, but I'm swamped with other stuff |
| 16:12 | <nickshanks> | or is it really small? i forget, one of them |
| 16:12 | <annevk> | Unless someone can take over editing of several specs from me |
| 16:12 | <nickshanks> | annevk: what are you working on? |
| 16:14 | <annevk> | xhr, xhr2, cssom, widgets and access-control |
| 16:14 | <annevk> | (that's part of my job though, there's more...) |
| 16:15 | <nickshanks> | hmm, http://dev.w3.org/cvsweb/csswg/cssom/Overview.html?rev=1.35#cssfontfacerule |
| 16:16 | <nickshanks> | IE, Prince and now WebKit have @font-face supported |
| 16:16 | <annevk> | I know |
| 16:16 | <nickshanks> | i wouldn't call it obsolete :) |
| 16:16 | <annevk> | Been a while since I looked at that |
| 16:16 | <annevk> | At that point the idea was to have font-family:url() |
| 16:21 | <annevk> | Might make sense to revamp that API anyhow |
| 16:24 | <hsivonen> | nickshanks: it appears that PDF doesn't have native arrowheads |
| 16:25 | <nickshanks> | okay, good. means i don't have to feel aggrieved at not having used them before :o) |
| 16:26 | <hsivonen> | nickshanks: do you write PDF in BBEdit, too? |
| 16:27 | <nickshanks> | no, not that skilled. i use adobe Illustrator (it's mostly creating resolution independent buttons for my software on Leopard) |
| 16:28 | <nickshanks> | though I ought to learn how. I am quite skilled at cleaning up SVG (reduce code size, optimising drawing etc) and i should learn the same for PDF |
| 16:29 | <nickshanks> | e.g. a filled circle and two stroked lines (pause button) is 20 KB |
| 16:32 | <nickshanks> | the SVGs I optimise at wikipedia tend to come out at between 8% and 50% of their original size |
| 16:33 | <hsivonen> | nickshanks: does wikipedia show SVG to new browsers? |
| 16:34 | <nickshanks> | no, it always returns the cached rasterisation |
| 17:12 | <MikeSmith> | zcorpan - you in Sweden? |
| 17:42 | <zcorpan> | MikeSmith: yes |
| 18:40 | <bewest> | would it be possible to get a bot in here similar to the ones in some other channels, where something like `input will tell the bot to provide the link to that element in the spec? |
| 18:44 | <bewest> | lol... if you get hit by a car, does it make you feel better that it's the driver's fault? |
| 18:46 | <zcorpan> | graceful error handling is like a car that doesn't hit anyone, even when the driver does things wrong |
| 18:46 | <bewest> | hmm... according to Don Norman, users first blame themselves when technology goes wrong; even when the issue clearly doesn't involve them |
| 18:47 | <bewest> | the first effect would probably be a reduced or even negative growth of people using the web |
| 18:59 | <Hixie> | did dan really just close down the html5 working group or is it my imagination |
| 19:00 | <Hixie> | i hope he doesn't expect progress on the spec to stop too... |
| 19:00 | <bewest> | did something other than "we suggest taking the weekend off" happen? |
| 19:00 | <othermaciej> | he ordered it to go on involuntary vacation until we have a tracking system and a review agenda |
| 19:00 | <othermaciej> | which I think is silly |
| 19:00 | <Hixie> | it's fine by me, i have to say |
| 19:00 | <othermaciej> | (on vacation from email/commenting) |
| 19:00 | <gsnedders> | Hixie: I guess it allows you to catch up :P |
| 19:00 | <Hixie> | comments still welcome on whatwg⊙wo! and on the whatwg forums! |
| 19:01 | <Hixie> | gsnedders: i'm caught up on public-html mail |
| 19:01 | <gsnedders> | Hixie: I mean all the back-suggestions, the 1000-odd emails |
| 19:01 | <Hixie> | oh, indeed |
| 19:03 | <Lachy> | anything that reduces the volume of email from public-html is fine by me. That'll give us more time to do the real work on whatwg :-) |
| 19:04 | <Hixie> | yeah |
| 19:04 | <Hixie> | i just don't get why danc would want whatwg to be the place to do work |
| 19:05 | <bewest> | Hixie: maybe because stuff actually gets done |
| 19:06 | <bewest> | public-html is full or arguments from people who apparently don't share the perspective outlined in the opera position paper back in 2004 |
| 19:06 | <bewest> | especially, the ideas of migration path and supporting existing content |
| 19:07 | <bewest> | s/full or/full of/ |
| 19:07 | <Hixie> | i don't know about "full of" |
| 19:07 | <bewest> | pregnant with |
| 19:08 | <Hixie> | there's maybe a dozen vocal opponents that i can see, most of which just seem generally confused (as opposed to having actual arguments against the proposed design critecial) |
| 19:08 | <Hixie> | criteria |
| 19:08 | <bewest> | yes, it's a property of the messages, not the membership |
| 19:08 | <Hixie> | indeed |
| 19:09 | <Hixie> | woot, iTunes claims to have fixed my Tao of Rodney! |
| 19:09 | Hixie | gets out his mac to download it |
| 19:10 | <Lachy> | what's Tao of Rodney? |
| 19:10 | <Hixie> | latest stargate atlantis episode |
| 19:10 | <Lachy> | which ep number? |
| 19:10 | <Hixie> | they accidentally uploaded the latest stargate sg-1 episode instead the first time |
| 19:11 | <Lachy> | ah, s3 e15. Seen that |
| 19:11 | <Hixie> | 14, i think |
| 19:11 | <Lachy> | yeah, typo |
| 19:11 | <Hixie> | s3 e14, episode id 315 |
| 19:11 | <Hixie> | (amusingly) |
| 19:11 | <Lachy> | yeah, I just noticed |
| 19:12 | <Hixie> | i hate that i could have seen all of sg1 and atlantis already if i didn't respect copyright laws |
| 19:12 | <Hixie> | i'm trying to throw money at this people and they won't take it fast enough! |
| 19:13 | <Lachy> | I respect them enough to not violate them when they give me a fair deal |
| 19:14 | <Lachy> | but I can't buy Stargate from iTunes cause I'm in Australia |
| 19:15 | <hsivonen> | let's hope that by the last day of XTech everyone know about HTML5, so that I can get rid of intro slides... |
| 19:15 | <bewest> | jgraham_: last time I loaded your parser view thing, it didn't seem to work. the lower pane was always empty |
| 19:32 | hsivonen | learns about http://www.exforms.org/ |
| 19:39 | <nickshanks> | did i not hear they were making a new stargate film |
| 19:39 | <Hixie> | they've been saying that since season 5 |
| 19:39 | <nickshanks> | but i mean that it's in production now that CG-1 has finished |
| 19:39 | <nickshanks> | *SG |
| 19:40 | <Hixie> | *shrug* |
| 19:41 | <Lachy> | yes, there's 2 direct-to-DVD films in production now |
| 19:41 | <Hixie> | direct to iTunes too, i hope |
| 19:42 | <Lachy> | yeah |
| 19:42 | <nickshanks> | does that mean i need to buy a cinema? |
| 19:42 | <Lachy> | I just meant, not going to the cinema |
| 19:42 | <nickshanks> | yeah, but so i can watch them in one? :) |
| 19:42 | <Lachy> | nickshanks, you will be required to buy an expensive home cinema :-) |
| 19:42 | hsivonen | believes the correct spelling is stargåte |
| 19:43 | <Lachy> | hsivonen, no, the A is replaced with the symbol for earth in the logo |
| 19:43 | <nickshanks> | well in the original film Daniel wrote the translation as "star gate" IIRC |
| 19:43 | <nickshanks> | on the chalkboard |
| 19:44 | <Lachy> | I don't think there was a space |
| 19:44 | <Lachy> | I could check if you like, I have the DVD here |
| 19:44 | <nickshanks> | i have the, erm, DivX handy too |
| 19:44 | <Hixie> | it's "STARGATE" |
| 19:45 | <Hixie> | no fancy anything, though some As are turned into /\ characters with a ring on top |
| 19:45 | <Hixie> | e.g. the second A in ATLANTIS |
| 19:45 | <Hixie> | or the second A in STARGATE-SG1 |
| 19:45 | <nickshanks> | obviously the first A isn't good enough |
| 19:46 | <hsivonen> | Hixie: my friends and I tend to pronounce it as if "gåte" was a Swedish word |
| 19:47 | <Hixie> | heh |
| 19:48 | Lachy | is looking forward to the first webisode of Sanctuary on Monday |
| 19:48 | <Hixie> | hsivonen: stahr-goh-te? :-) |
| 19:48 | <hsivonen> | Hixie: yes |
| 19:49 | <Hixie> | hehe |
| 19:49 | <Lachy> | what the? Does that sound like star-goat? |
| 19:49 | <Hixie> | "stahr-goh-teh", rather |
| 19:49 | <Lachy> | ok |
| 19:50 | <Hixie> | probably emphasised "stahrGoh-teh" |
| 19:50 | <nickshanks> | enter the star goat |
| 19:50 | <Hixie> | anyway |
| 19:50 | <Hixie> | i'm gonna go grab a burrito |
| 19:50 | <Hixie> | and watch my stargoat! |
| 19:50 | <Lachy> | :-) |
| 19:50 | <Lachy> | I'm off to bed, g'night all |
| 19:52 | <hsivonen> | Lachy: nn |
| 19:57 | <nickshanks> | @media print { paper-source: cotton; denomination: "£20"; watermark: queens-head; } |
| 20:05 | <maikmerten> | hello, I'm just dropping news that Wikipedia now supports <video> as implemented by the experimental Opera build |
| 20:05 | <maikmerten> | see http://commons.wikimedia.org/wiki/Category:Video for a list of available video files |
| 20:05 | <maikmerten> | or see it directly in action e.g. at http://tools.wikimedia.de/~gmaxwell/jorbis/commonsJOrbisPlayer.php?path=Controlled+Impact+Demonstration+2.ogg |
| 20:06 | <hasather> | maikmerten: cool, thanks |
| 20:06 | <maikmerten> | hasather, well, I only wrote the detection code, I'm not connected to Wikipedia, so I'll just route your thanks into the correct direction |
| 20:07 | <maikmerten> | that online player checks for <video>, VLC plugin, any plugin registering application/ogg or uses Java (if available) as fallback |
| 20:07 | <maikmerten> | so it's pretty versatile |
| 20:08 | <maikmerten> | and enables video playback on e.g. Ubuntu out of the box (Ubuntu comes with the Totem browser plugin by default, and that of course supports Ogg) |
| 20:13 | <hsivonen> | maikmerten: cool! |
| 20:14 | <maikmerten> | yeah, I'm glad Wikipedia is so quick adopting new stuff |
| 20:14 | <maikmerten> | and I'm sure this gives a nice testbed for browser implementations |
| 20:14 | <maikmerten> | (at least for the basic features... play... stop... buffering...) |
| 20:15 | <jgraham> | bewest: WFM with google.com (it's kinda slow though). Does it break everywhere for you? If it's just a few sites then there might be a bad interaction between the site and the script that builds the DOM |
| 20:15 | <jgraham> | specifically I think document.write running on page load will break everything |
| 20:16 | <othermaciej> | wikipedia adopting it is a little worrisome, especially since Opera's experimental implementation likely doesn't match the spec any more |
| 20:17 | <maikmerten> | othermaciej, it's only using play() and stop()... I don't think that'll ever break |
| 20:17 | <maikmerten> | and of course it'll be fitted to the final spec |
| 20:17 | maikmerten | looks at the current draft to see if something vital has changed |
| 20:25 | <maikmerten> | hmm... actually I'm too blind to see stop() anywhere |
| 20:25 | <maikmerten> | there's play() and pause(), but I'm missing stop() |
| 20:26 | <zcorpan> | maikmerten: perhaps it was dropped? :) |
| 20:26 | <maikmerten> | perhaps |
| 20:26 | <maikmerten> | but then I don't see a valid replacement for it |
| 20:27 | <othermaciej> | most video player UIs don't actually have a stop operation |
| 20:27 | <maikmerten> | (currently I don't see how you'd properly restart media file playback) |
| 20:27 | <othermaciej> | but if you want one, you can pause() and reset the current time to start |
| 20:28 | <maikmerten> | okay, that sounds like a plan |
| 20:28 | <maikmerten> | an idea if the experimental Opera build supports that... |
| 20:28 | <maikmerten> | well, nah, doesn't matter |
| 20:28 | <maikmerten> | software shouldn't be written against that |
| 20:28 | <maikmerten> | otherwise people will rightfully scream "what part of 'experimenta' didn't you get?" ;-) |
| 20:29 | <maikmerten> | s/experimenta/experimental |
| 20:35 | <maikmerten> | okay, I'd say "document.getElementById(\"video_element\").pause(); document.getElementById(\"video_element\").start = 0;" should mimic a stop button |
| 20:36 | <maikmerten> | in the public (outdated, so it seems) Opera build setting start to zero doesn't seem to work |
| 20:41 | <zcorpan> | there is a public build of opera that supports <video>? |
| 20:42 | <maikmerten> | labs.opera.com |
| 20:42 | <maikmerten> | but seems the API isn't following the current <video> draft |
| 20:42 | <maikmerten> | (no surprise, that build isn't really fresh anymore) |
| 20:43 | <maikmerten> | (plus: it's experimental) |
| 20:44 | <zcorpan> | oh, i thought it was internal builds only |
| 20:44 | zcorpan | is installing |
| 20:44 | <zcorpan> | separate or upgrade? |
| 20:44 | <maikmerten> | I'd strongly advise installing it separately |
| 20:44 | <zcorpan> | yeah |
| 20:47 | <zcorpan> | ooh, nice! |
| 20:47 | zcorpan | plays in a data: uri |
| 20:50 | <hsivonen> | too many slides :-( |
| 20:50 | <hsivonen> | have to take out the IDness stuff :-( |
| 20:51 | <zcorpan> | perhaps class="" should always signal classness |
| 20:53 | <maikmerten> | okay, the wikimedia player now has a pause button instead of stop (that'll get reintroduced once the draft is stable and there are new builds with the new API implemented) |
| 20:53 | <maikmerten> | I guess play() and pause() will stick, so that should be safe |
| 21:02 | <maikmerten> | oh, and in case the JavaScript you can see in that Wikipedia player is blinding you: Don't blame them, blame me. I haven't written JavaScript for years and never was good in it to begin with ;) |
| 21:03 | <maikmerten> | (just the usual disclaimer, guess some real web programming experts may be in this channel) |
| 21:20 | <Hixie> | nice summary http://www.sitepoint.com/blogs/2007/05/10/six-months-later-the-new-html-working-group/ |
| 21:20 | <hsivonen> | hmm. so now the title of the spec is "HTML 5" not "HTML5" |
| 21:21 | <Hixie> | what's the difference? |
| 21:21 | <hsivonen> | Hixie: the space |
| 21:21 | <Hixie> | if people want some trivia that distinguishes us from other people, we can say that "HTML 5" is the name of the spec and "HTML5" is the name of the language... |
| 21:22 | <hsivonen> | :-) |
| 21:22 | <hsivonen> | I guess omitting the space is the WHATWG shibboleth |
| 21:23 | <Hixie> | it's like CSS21 vs CSS 2.1 |
| 21:23 | <Hixie> | i'm kinda happy with the abstract of the w3c version of the html5 spec |
| 21:24 | <Hixie> | it ushers in the new wave of spec design and brushes off the last few years of non-work all in one neat paragraph |
| 21:30 | <othermaciej> | I'm surprised to see someone call the HTML5 proposal a "Surprise Proposal" |
| 21:31 | <Dashiva> | Is the w3 version linked anywhere yet? |
| 21:31 | <Hixie> | dev.w3.org/cvsweb/html5/spec/ |
| 21:31 | <Hixie> | iirc |
| 21:32 | <Philip`> | http://dev.w3.org/cvsweb/~checkout~/html5/spec/Overview.html?content-type=text/html;%20charset=utf-8 specifically, but cvsweb will hate you for downloading it |
| 21:32 | <Hixie> | yeah that's kinda funny |
| 21:32 | <Hixie> | you download it and it locks you out :-) |
| 21:33 | <Dashiva> | Not like I -wanted- to use that mean web server anyway. I bet it has cooties :p |
| 21:55 | <Hixie> | 29 canvas e-mails remaining |
| 21:55 | <Hixie> | other than those asking for a text output api |
| 22:00 | <hsivonen> | Hixie: will you reconsider dashed stroking? |
| 22:02 | <Hixie> | yeah, there's a bunch of mail outstanding on it from a few days ago |
| 22:03 | <Hixie> | from a quick skim i didn't see anything that seemed convincingly in favour of it though |
| 22:03 | <Hixie> | especially given the demo |
| 22:04 | <hsivonen> | Hixie: not even that it seems to be a standard part of the PostScript/PDF imaging model? |
| 22:04 | <Hixie> | how is that relevant? |
| 22:04 | <hsivonen> | Hixie: presumably, offering it is cheap if back end libraries implement it anyway |
| 22:04 | <Hixie> | plenty of things are cheap, but not offered |
| 22:06 | <hsivonen> | I thought canvas was supposed to put a JS API on the PDF imaging back end with all the usual stuff |
| 22:07 | hsivonen | uses dashed strokes in static diagrams relatively often |
| 22:07 | <Hixie> | nope, it just provides a js direct mode bitmap api |
| 22:07 | <Hixie> | it's not an api to any particular undelying api |
| 22:07 | <Hixie> | understand that i'm not particularly against dashed strokes, i'm just trying to keep the api to a minimum, and so something has to be cut -- and dashed strokes simply aren't very frequently requested |
| 22:08 | <Hixie> | if we did add dashed strokes, though, i bet the next request would be control the dash pattern |
| 22:08 | <hsivonen> | of course I was expecting control of the dash pattern |
| 22:08 | <Hixie> | see, it's a slippery slope :-) |
| 22:08 | <hsivonen> | i.e. exposing the PDF 1.4 drawing back end in JS |
| 22:08 | <Dashiva> | Guys, you need to be more semantic in your use of dash, so my highlighter knows if it refers to me :) |
| 22:09 | <Hixie> | hah |
| 22:10 | <hsivonen> | Hixie: it appears I've misunderstood what canvas is supposed to be. :-/ |
| 22:10 | <Hixie> | i don't understand why you thought it had anything to do with a particular underlying api |
| 22:11 | <hsivonen> | Hixie: not API but imaging model |
| 22:11 | <hsivonen> | Hixie: PostScript begat PDF, PDF begat Quartz 2D, Quartz 2D begat canvas |
| 22:11 | <Hixie> | it's certainly not that simple at either of those steps, though i agree there was strong influence down that line |
| 22:12 | <hsivonen> | Hixie: I expect canvas to expose the PDF 1.4 imaging model in a way that maps reasonably to C libraries designed to implement the imaging model |
| 22:12 | <hsivonen> | Hixie: I understand that you don't want more than one way to do things when canvas already does something. |
| 22:13 | <hsivonen> | Hixie: but dash arrays are a hard-to-emulate part of the imaging model |
| 22:13 | <Hixie> | so's text |
| 22:13 | <Hixie> | and we don't have that |
| 22:13 | <hsivonen> | Hixie: not text layout |
| 22:13 | <Hixie> | we don't have any text at all |
| 22:13 | <hsivonen> | Hixie: only drawing a glyph at the current point |
| 22:14 | <Philip`> | About the dash demo, apparently it fails unpleasantly on certain curves and sharp corners. That might just be a fixable bug in the demo, but it's a bit messy and still can't do proper dashed curves |
| 22:14 | <Hixie> | Philip`: indeed |
| 22:14 | <hsivonen> | Hixie: exposing text is harder than exposing dashing |
| 22:14 | <Hixie> | i'm just saying that we're not trying to be the be-all and end-all of all drawing APIs |
| 22:14 | <Philip`> | (s/it's a bit messy/any approach based on simulating dashes within JS/) |
| 22:14 | <Hixie> | some features don't make the cut |
| 22:14 | <hsivonen> | Hixie: it's not like dashing is something that back ends would have to add. they have it already |
| 22:15 | <Hixie> | hsivonen: i'm not making any arguments regarding the complexity of implementation |
| 22:17 | <jgraham> | FWIW I would expect dashed lines to be present too for e.g. plotting applications |
| 22:22 | <Philip`> | http://canvaspaint.org/ - that's doing dashed lines (for the selection tool) |
| 22:23 | <zcorpan> | Philip`: cool! |
| 22:25 | <Philip`> | It looks like it's using the image http://canvaspaint.org/icons/dashed2.gif as a repeated pattern in order to draw the dashed outline |
| 22:26 | <Philip`> | which won't work at all for non-rectangular selections (which aren't supported in that program - don't know if that's because the dashes were too hard or the whole selection thing was too hard) |
| 22:27 | <othermaciej> | I think dashed strokes aren't a very extreme feature |
| 22:27 | <othermaciej> | but maybe better saved for the next version |
| 22:27 | <Hixie> | this whole editing the spec thing would be going much better if cgi.w3.org wasn't dead |
| 22:28 | <Philip`> | Was v2 mostly adding setTransform? (I can't remember what else seemed new...) |
| 22:29 | <Philip`> | and has anybody released a browser with the v2 features yet? |
| 22:29 | <Hixie> | getImageData/putImageData, setTransform, and isPointInPath |
| 22:29 | <Philip`> | Ah, okay |
| 22:30 | <Hixie> | and maybe transform() |
| 22:30 | <Hixie> | i don't recall |
| 22:30 | <Philip`> | I wouldn't have thought it's too late now to add things to v2, since it doesn't need to be frozen for compatibility if nobody's released it yet |
| 22:31 | <Hixie> | you don't freeze a spec when an implementation is released, you freeze a year before release |
| 22:32 | <Hixie> | also, every feature added is expensive, though some are even more expensive than others |
| 22:32 | <Philip`> | Oh, that makes sense |
| 22:32 | <Hixie> | so you have to go slowly |
| 22:33 | <othermaciej> | I'm still not sure getImageData is sensible |
| 22:34 | <Philip`> | The specific definition, or the whole concept? |
| 22:34 | <Philip`> | I like the concept because it means I can write canvas tests without having to manually check the output of hundreds of them :-) |
| 22:35 | <Hixie> | othermaciej: oh? |
| 22:35 | <othermaciej> | given the possibility of device-specific scaling, it's hard to make interoperable code that actually reads the data |
| 22:35 | <Philip`> | (Actually, I guess I could work around that by assuming toDataURL is deterministic and then extracting a pixel into a new canvas and toDataURLing and comparing to a known image... That'd be very evil, though) |
| 22:35 | <othermaciej> | using it with putImageData is fine, but reading the pixels is dubious |
| 22:36 | <Hixie> | othermaciej: the expected use case is you read the data with getID, apply a filter to all the data, then put it back with putID |
| 22:36 | <Hixie> | othermaciej: you're not really expected to get single pixel values (though i'm sure people will) |
| 22:36 | <othermaciej> | the data attribute is readonly - how would you apply a filter? |
| 22:36 | <Hixie> | the reference to the array is readonly. the actual pixels aren't. |
| 22:37 | <othermaciej> | oh |
| 22:37 | <othermaciej> | is that how IDL works? |
| 22:37 | <Hixie> | it's how my IDL works |
| 22:37 | <Hixie> | :-) |
| 22:37 | <Hixie> | the IDL in the html5 spec is a mess |
| 22:37 | <Hixie> | there's a big thing about that at the top |
| 22:38 | <othermaciej> | anyway, since the width and height might be different even if you got image data the same box, it seems likely to have potential for interop problems |
| 22:38 | <othermaciej> | in fact, any filter you did that isn't scale-independent would have to figure out the scale factor |
| 22:39 | <othermaciej> | (like gaussian blur with a radius of 3 canvas pixels, if there's a 2x device scale factor, would have to be done as a 6 pixel blur) |
| 22:39 | <othermaciej> | I'm not really sure how to solve this though |
| 22:40 | <Philip`> | Are people going to want to implement it with a non-integer number of device pixels per canvas pixel? |
| 22:40 | <Hixie> | yeah what's in the spec seems like the best of a bad set of options |
| 22:40 | <othermaciej> | Philip`: probably, yes |
| 22:40 | <othermaciej> | Mac OS X supports non-integral UI scale factors |
| 22:41 | <othermaciej> | perhaps making the canvas pixel to device pixel scale factor directly visible in the API would make this a bit more clear |
| 22:41 | <othermaciej> | I dunno |
| 22:43 | <Philip`> | Would it be bad to make the canvas use a number of device pixels that's an integer multiple of the canvas pixels, then scale the final bitmap up by a non-integer amount before drawing to the screen? That'd probably avoid the nasty cases of getImageData not mapping to a simple well-defined group of device pixels |
| 22:44 | <othermaciej> | yes, that's possible |
| 22:44 | <Philip`> | (Then ImageData could just tell you the number of device pixels per canvas pixel, and you could work everything out by easy multiplication, without worrying about rounding and things) |
| 22:45 | <othermaciej> | though if your scale factor is 4:3, you need a 3x buffer, which is a little sad |
| 22:48 | <Philip`> | I was thinking you could store a 1x buffer then scale the bitmap by 4/3 when copying to the screen, or a 2x buffer and scale by 2/3 (which I guess would be less blurry output). Might not look good in practice, though |
| 22:49 | <Hixie> | it doesn't actually matter in practice |
| 22:49 | <Hixie> | because getID and putID only deal with device pixels |
| 22:49 | <Hixie> | not canvas pixels |
| 22:49 | <Hixie> | (other than for selecting the region, but that's a float) |
| 22:51 | <Philip`> | The problem is in the mapping between device pixels and canvas pixels - I think it'd be much easier to understand if you could call getImageData(x, y, 1, 1) and be certain you'll get n*m pixels (for some known positive integers n and m), rather than getting some arbitrary number that depends on x and y and could be zero |
| 22:51 | <Hixie> | why would you call gID with 1,1? |
| 22:52 | <Philip`> | To find the colour of a pixel, like with the colour-picker tool in a paint program |
| 22:53 | <Hixie> | for that case you can just use the first pixel |
| 22:53 | <Hixie> | where's the problem? |
| 22:53 | <Philip`> | As far as I understand it, it could return zero pixels of data |
| 22:53 | <Hixie> | why? |
| 22:53 | <othermaciej> | Philip`: it could only be zero if you have a < 1 scale factor |
| 22:54 | <hsivonen> | hmm. three XTech timeslots where I find it hard to decide which session to attend... |
| 22:54 | <Philip`> | Does anything prevent there being a < 1 scale factor? |
| 22:54 | <othermaciej> | Philip`: I think with non-integer scale factors of the backing store, implementing the requirement that putImageData(getImageData()) be idempotent is extremely difficult |
| 22:54 | <Hixie> | surely it's just a matter of rounding the same way? |
| 22:56 | othermaciej | thinks |
| 22:57 | <othermaciej> | maybe that part is not hard; more that doing a putImageData() at a different location of the same data could have odd-looking results |
| 22:57 | <othermaciej> | you could get cracks where you expected things to line up seamlessly |
| 22:57 | <Hixie> | yup, but if you want to move data, you should use drawImage() |
| 22:58 | <Hixie> | gID and pID really are only for two use cases, applying filters, and the colour picker -- for the colour picker case maybe i should make the spec guarentee that h*w >= 1 |
| 23:03 | <zcorpan> | perfect! now i know how we should make the spec easier to read! http://venturebeat.com/2007/05/10/live-ink-offers-better-way-to-read-text-online/ |
| 23:04 | <Philip`> | For filters that need to know the device scale factor (Gaussians etc), I suppose you could estimate it by dividing the returned .width and the parameter sw, at least for large enough areas that you won't get rounding problems - I don't know whether it'd be worth having ImageData explicitly tell you the scale factor |
| 23:05 | <Hixie> | zcorpan: you want me to turn the spec into one long poem? :-) |
| 23:06 | <zcorpan> | yeah :) |
| 23:06 | <zcorpan> | it would turn it into 1500 pages in print |
| 23:07 | <hsivonen> | zcorpan: they aren't eating their own dogfood for their paper |
| 23:08 | <zcorpan> | http://www.accessifyforum.com/viewtopic.php?p=52490#52490 |
| 23:40 | <hsivonen> | http://en.wikipedia.org/w/index.php?title=Web_Hypertext_Application_Technology_Working_Group&curid=1789925&diff=125647714&oldid=123198165 |
| 23:40 | <Hixie> | heh |
| 23:40 | <Hixie> | that's news to me |
| 23:41 | <Dashiva> | Well, they wouldn't be very undercover if they told you |
| 23:41 | <Hixie> | that page has so many errors |
| 23:41 | <Hixie> | anyway |
| 23:42 | <othermaciej> | but it's Truthy! |
| 23:42 | <hsivonen> | reverted |
| 23:43 | <Hixie> | the version of reality before you reverted was better |
| 23:44 | <Dashiva> | We need a quantum wikipedia, which alters reality to the truth you edit into it |
| 23:44 | <hsivonen> | Hixie: how so? |
| 23:44 | <Hixie> | that would be really freaking dangerous |
| 23:44 | <Hixie> | hsivonen: if microsoft actually were involved, it would be awesome |
| 23:45 | <Hixie> | (in the whatwg, i mean) |
| 23:45 | <hsivonen> | I see |
| 23:46 | <zcorpan> | data: [i for (i in function (n) { for (let i = 0; i < n; i += 1) yield 0 }(w*h*4)) ] |
| 23:47 | zcorpan | dosn't recognize that syntax :| |
| 23:47 | <Hixie> | js 1.7 |
| 23:47 | <Dashiva> | also known as pythonscript |
| 23:47 | <bewest> | ooOoooo |
| 23:47 | <Philip`> | http://developer.mozilla.org/en/docs/New_in_JavaScript_1.7 |
| 23:47 | <Hixie> | (works in fx2) |
| 23:49 | <zcorpan> | i get "Error: missing ; after for-loop initializer" |
| 23:49 | <dbaron> | there should *really* be a simpler way to do that |
| 23:50 | <Philip`> | It'd be better if they copied more of Python and let you write "[0] * (w*h*4)" |
| 23:51 | <Hixie> | zcorpan: make sure you say <script type="text/javascript;version=1.7"> |
| 23:52 | <zcorpan> | ah |
| 23:52 | <zcorpan> | ok |
| 23:55 | <zcorpan> | Hixie: "There's still no way to _get_ the transformation matrix, but you can not _set_ the transformation matrix now, which should be of help here." did you mean s/not // ? |
| 23:56 | <Hixie> | i meant "now" |
| 23:56 | <Hixie> | oops |
| 23:56 | <Hixie> | always get those mixed up |
| 23:57 | <zcorpan> | that's what you get for using dvorak :P |
| 23:57 | <Hixie> | hehe |
| 23:57 | <Hixie> | actually i get them confused in qwerty too |
| 23:57 | <Hixie> | i think it's a brain thing |
| 23:57 | <Hixie> | not a finger thing |
| 23:58 | <zcorpan> | oh |
| 23:58 | <Hixie> | i notice a lot of other people doing it too |
| 23:58 | <dbaron> | is one of them me? |
| 23:59 | <Hixie> | dunno |
| 23:59 | <Hixie> | maybe :-) |
