| 00:27 | <Hixie> | http://groups.google.com/group/opera.general/browse_thread/thread/c815c26e44f91c3c/2cef47d6d17f260e?q=whatwg&rnum=1#2cef47d6d17f260e |
| 00:28 | <Hixie> | what an amusingly dismissive last two lines |
| 00:41 | <Hixie> | lol, i just saw the tagline from this channel got put on the blog |
| 00:42 | <zcorpan_> | that was a while ago, i think |
| 00:43 | <Hixie> | i don't read our blog that often :-P |
| 00:50 | <zcorpan_> | btw, i got employed at opera, so i can continue to work full-time on html5 :) |
| 00:50 | <Hixie> | nice |
| 01:45 | Hixie | works his way towards emptying his mailbox of anything other than whatwg and public-html mail |
| 01:52 | <Lachy> | hsivonen, yt? |
| 01:55 | <Lachy> | hsivonen, compare http://validator.nu/?doc=http%3A%2F%2Flachy.id.au%2Ftemp%2Fid.xhtml and http://validator.nu/?doc=http%3A%2F%2Flachy.id.au%2Ftemp%2Fid.html |
| 01:55 | <Lachy> | the first in XHTML, the other is HTML. Why is the validity of the id attribute different? |
| 01:56 | <Hixie> | IDs in XML can't start with numbers |
| 01:56 | <Hixie> | according to XML |
| 01:57 | <Lachy> | welcome back Hixie! |
| 01:57 | <Hixie> | not sure what this means in terms of HTML5 though |
| 01:57 | <Hixie> | thanks :-) |
| 01:57 | Hixie | started the day with ~8000 e-mails |
| 01:57 | <Hixie> | down to ~4000 |
| 01:57 | <Lachy> | I thought that XML issue related to the validity constraint with XML DTDs, and since we're not using DTDs, it didn't matter |
| 01:58 | <Hixie> | yeah, i assume he's got some XML stuff in there somewhere though :-) |
| 01:58 | <Lachy> | did you notice the poll for the selectors api naming debate? That closes later today, if you wanted to put in your vote |
| 01:58 | <Hixie> | done already |
| 01:59 | <Lachy> | cool |
| 01:59 | <othermaciej> | having a poll for that was slightly silly |
| 01:59 | <othermaciej> | but an online poll is still better than a voice vote at a face-to-face meeting |
| 01:59 | <Hixie> | that was the gist of my comment on the poll |
| 02:00 | <deltab> | the xml:id spec requires NCName for ids (not that XHTML uses xml:id) |
| 02:00 | <deltab> | (so it's not just a DTD thing) |
| 02:01 | <Hixie> | in XML it's a DTD thing |
| 02:01 | <Hixie> | in XMLID it's an XML ID thing |
| 02:01 | <Hixie> | in RelaxNG it's a RelaxNG thing |
| 02:01 | <Hixie> | etc :-) |
| 02:01 | <Hixie> | just happens many of them agree |
| 02:02 | <Hixie> | (insert rant about whatwg being affected by "not invented here" syndrome here, and rant about how whatwg ignores industry practices, etc) |
| 02:03 | <Lachy> | then I wonder why hsivonen's validator marks them different, since I thought it uses RelaxNG for checking some validity issues for both serialisations |
| 02:05 | <zcorpan_> | it may be that id processing isn't done at all on the html side. or something. |
| 03:11 | <Lachy> | Hey, I'm looking for a couple of example sites where <meter> could be useful. Any ideas? I need the use cases for my presentation I'm doing on Friday |
| 03:12 | <Lachy> | oh, YouTube is a perfect example! |
| 03:19 | <Hixie> | Lachy: the example in the spec is from google groups |
| 03:20 | <Lachy> | yeah, I could show that too |
| 03:20 | <Hixie> | there's also the usual thinks like disk usage (google docs, webmail apps) |
| 03:21 | <Lachy> | ah, the spec even has a nice image for me to steal :-) |
| 03:21 | <Hixie> | :-) |
| 03:24 | <Lachy> | the spec shows this example <meter><object data="graph75.png">0.75</object></meter>, does that work with <img> too? |
| 03:24 | <Hixie> | yup |
| 03:24 | <Hixie> | uh wait |
| 03:24 | <Hixie> | no |
| 03:24 | <Hixie> | we don't yet scan alt="" iirc |
| 03:25 | <Hixie> | though mind you, i haven't even looked at the spec in 3 weeks |
| 03:25 | <Hixie> | so what do i know :-P |
| 03:26 | <Lachy> | ok, I'll use the object example. Is the intention that it would render the image, instead of generating its own bargraph? |
| 03:27 | <Lachy> | (perhaps I should have spent more time working on this, instead of cramming at the last minute) |
| 03:28 | <Lachy> | ah, it probably wouldn't.The image would probably just be fallback for UAs that don't support meter |
| 03:28 | <Hixie> | yeah |
| 03:28 | <Hixie> | the latter |
| 03:30 | <Lachy> | google groups doesn't appear to use that bar graph any more |
| 03:39 | <Hixie> | heh |
| 05:33 | Hixie | wonders what he's supposed to do with http://www.w3.org/mid/op.tvg629ividj3kv@hp-a0a83fcd39d2 |
| 05:34 | <Hixie> | i already examined what the browsers did when i wrote the spec |
| 05:34 | <Hixie> | and the e-mail doesn't point out any problems |
| 05:58 | <Lachy> | without evidence to show that sites depend on one particular behaviour over another, I think the spec is fine as is |
| 06:06 | <Lachy> | Hixie, see the comments. http://www.search-this.com/2007/07/30/html5-tables/ |
| 06:06 | <Lachy> | Looks like a possible bug in the table header algorithm. |
| 06:06 | <Hixie> | yeah known issue |
| 06:06 | <Lachy> | ok |
| 06:06 | <Hixie> | my implementation fixes it |
| 06:07 | <Hixie> | i'll port that back to the spec in due course |
| 06:07 | <Lachy> | cool |
| 06:07 | <Hixie> | (the implementation that i used to test whether headers="" helped, that is) |
| 06:07 | <Hixie> | at least if i understand this right |
| 06:07 | <Hixie> | the second comment confused me |
| 06:08 | <Lachy> | I noticed that algorithm doesn't seem to deal with <table><col>, only with <table><colgroup><col> |
| 06:08 | <Hixie> | yeah |
| 06:08 | <Hixie> | didn't know <table><col> was allowed in XHTMl1 |
| 06:08 | <Lachy> | it's not, but the algorithm should still deal with it |
| 06:08 | <Lachy> | oh, in XHTML 1, yes it is allowed |
| 06:09 | <Hixie> | yeah we'll have to fix that |
| 06:09 | <Hixie> | there was a mail about it, iirc, i think i saved it to my semantics-table pile |
| 06:10 | <Lachy> | I started writing a JS implementation of it last night. |
| 06:14 | Hixie | fears the "conflation of issues or convergence of interests?" thread |
| 06:14 | <Lachy> | actually, that thread has turned out to be quite constructive, for the most part |
| 06:14 | <Hixie> | how unlikely |
| 06:15 | <othermaciej> | hola |
| 06:15 | <othermaciej> | Hixie: there are some offshoots which are not completely insane |
| 06:16 | <othermaciej> | and in any case it is way better than "Re: Formal Recorded Complaint" |
| 06:16 | <Hixie> | hey maciej |
| 06:16 | <othermaciej> | hello Hixie |
| 06:16 | <othermaciej> | back from vacation? |
| 06:16 | <Hixie> | yeah |
| 06:17 | <othermaciej> | cool, did you have a good holiday? |
| 06:17 | <Hixie> | it was... different from work |
| 06:17 | <othermaciej> | well yes, that's the bare minimum one should expect |
| 06:18 | <Hixie> | mostly it was tiring :-) |
| 06:18 | <Hixie> | i started today with 8000 e-mails |
| 06:18 | <Hixie> | i now have 1100 |
| 06:19 | <othermaciej> | that's good progress |
| 06:19 | <Lachy> | how on earth do you read so many emails that quickly? |
| 06:20 | <Hixie> | i'm on a LOT of mailing lists, and i don't do more than scan the subject lines of most of them |
| 06:20 | <Hixie> | e.g. i don't do more than scan the subject lines of www-tag |
| 06:21 | <Lachy> | lol, that's what I do with www-tag too |
| 06:21 | <Hixie> | most of the remainder are those that i have to actually read |
| 06:37 | <Lachy> | in what cases would it be advantageous to use <progress value="60"> instead of just <progress>60%</progress> (or some other appropriate content within the element)? |
| 06:39 | <Lachy> | oops, that should be <progress value="0.6"> |
| 06:40 | <othermaciej> | Lachy: is <progress> expected to render the content text anywhere? |
| 06:40 | <othermaciej> | if so, you might want an amount of kilobytes or something |
| 06:40 | <Lachy> | only as fallback |
| 06:40 | <othermaciej> | instead of a percentage |
| 06:44 | <Lachy> | oh, I see, it's an advantage when you want to be able to get progress.value, since that would return 0 without the attributes. It never reflects the value parsed from textContent |
| 07:04 | <hsivonen> | Lachy: your HTML doc was HTML5. your XHTML doc was versionless and the validator picked XHTML 1.0 because XHTML5 is not near CR yet |
| 07:05 | <Lachy> | oh |
| 07:05 | <Lachy> | I see, it validates if I select HTML5 manually |
| 07:06 | <Lachy> | s/HTML5/XHTML5/ |
| 07:08 | <hsivonen> | Hixie: btw, IDs in XML are crazier than just being a DTD thing or an xml:id thing. the permitted charecters in IDs are different in DTDs and in xml:id. |
| 07:08 | <hsivonen> | validator.nu has a long-standing bug here |
| 07:09 | <hsivonen> | (inherited from elsewhere) |
| 07:09 | <hsivonen> | the bug being that the colon is not allowed in IDs for XHTML 1.0 |
| 07:10 | <hsivonen> | because the schema uses the XSD definition of ID, but XHTML 1.0 should be subject to the DTD definition of ID |
| 07:26 | <Lachy> | hsivonen: do you have any idea about the origin of the character restrictions in ID and why they are the way they are? |
| 07:57 | <hsivonen> | Lachy: I don't *know* but I imagine the restriction to Name in XML 1.0 comes from SGML tradition and the production for Name comes from a feeling the for aesthetics Names should capture a certain letter-like format |
| 07:58 | <hsivonen> | Lachy: as for why XSD and xml:id used NCName instead, I can only guess that the writes of the specs didn't want IDs to look like QNames-in-content |
| 07:59 | <hsivonen> | Lachy: anyway, Real Software needs to check those string for equality and both the Name and NCName production are arbitrary |
| 07:59 | <Hixie> | hsivonen: fun |
| 08:21 | <MikeSmith> | I suspect the reason for character restrictions in ID values is for reasons similar to character restrictions in symbol names in programming languages |
| 08:21 | <MikeSmith> | and in filesystems |
| 08:21 | <annevk> | wb Hixie |
| 08:23 | <hsivonen> | MikeSmith: and in filesystems, the historical convergence has been towards allowing everything except the character reserved for separating path segments |
| 08:24 | <hsivonen> | MikeSmith: because eventually someone out there wants to use characters that don't fit the sense of aesthetics of the spec writer |
| 08:24 | <hsivonen> | MikeSmith: and no techical badness ensues so it is hard to deny them |
| 08:32 | <MikeSmith> | hsivonen - you won't get any disagreement from me about that. Just was chiming in to speculate on what the thought behind the restriction might have been. FWIW, I've personally run into real-world instances where constraints on ID values are completely counter productive. So I'm not suggesting I think they're sound. |
| 08:33 | <MikeSmith> | I think it's enough of a problem that any tool or processing app that does constraint-checking on ID/xml:id values should offer a switch for disabling it. |
| 10:58 | <annevk> | jgraham, should we tackle it for HTML5 though or let it rest for HTML6 to tackle? |
| 10:58 | <annevk> | HTML5 already tackles so many issues and there hasn't been much experimental stuff happening yet with namespaces in HTML except one failed attempt at Opera (recognizing xmlns) |
| 11:15 | <hsivonen> | annevk: can you say whether Opera has tried hardwiring well-known prefixes? |
| 11:29 | <annevk> | hsivonen, I don't think we did, but what exactly do you mean? |
| 11:38 | <hsivonen> | annevk: I mean hardwiring the rdf prefix to the RDF namespace, the dc prefix to dublin core namespace, svg to svg namespace, etc. |
| 11:39 | <annevk> | so you would have to write <svg:svg> etc. ? |
| 11:40 | annevk | does not really like that approach |
| 11:44 | <hsivonen> | annevk: I'd like to have scope-based ns mapping for <svg> and <math> subtrees, yes. |
| 11:45 | <hsivonen> | but yes, I did mean doing hardwired things with colonified names |
| 11:46 | <annevk> | and how do you deal with empty elements? |
| 11:47 | <hsivonen> | annevk: /> would have to close the element when in the tag name is colonified or in <svg> or <math> scope |
| 11:47 | <annevk> | hmm |
| 11:48 | <hsivonen> | I care more about <svg> and <math> scoping than about colonified names (except xlink:href) |
| 11:48 | <zcorpan_> | or we make certain tags void? |
| 11:49 | <hsivonen> | zcorpan_: that would miss an opportunity to be forward-compatible with new empty elements added later to MathML or SVG |
| 11:49 | <zcorpan_> | true |
| 11:50 | <annevk> | I'm afraid of breakage |
| 11:50 | <annevk> | I'd rather let this wait until HTML5 parsing itself is reasonably interoperable |
| 11:52 | <hsivonen> | annevk: I agree we should probably not tackle this in the next 6 months, but I think it is important to make SVG more competitive vs. proprietary closed web technologies |
| 11:56 | <Lucian> | hi |
| 11:56 | <annevk> | hi |
| 11:58 | <annevk> | hsivonen, yeah, that's a fair point I suppose |
| 12:13 | <hsivonen> | annevk: fwiw, the text scaling issue applies to font zoom and em-sized canvases anyway |
| 12:14 | <annevk> | well, I meant that if the canvas size depended on the size of the div |
| 12:14 | <annevk> | that is, if the canvas grid depended on the rendered size of the <div> |
| 12:14 | <annevk> | (the canvas grid for <canvas> depends on width and height, which simply take integers) |
| 12:15 | <hsivonen> | oh. I missed the point |
| 12:17 | <annevk> | I suppose it was not clear |
| 13:08 | <hsivonen> | whoa! the XHTML2 WG namespace minutes are 11 months old! |
| 13:13 | <zcorpan_> | how is "version 1.0 or later of XML" different or more specific than "some version of XML"? |
| 13:17 | <hsivonen> | zcorpan_: it looks more rigorous than "some" |
| 13:18 | annevk | made http://html5.org/ more usable |
| 13:37 | <annevk> | hsivonen, isn't the table sorted? |
| 13:39 | <Philip`> | It isn't - it puts "AElig;" before "AElig" |
| 13:39 | <annevk> | Hixie, help-whatwg and implementors-whatwg are affected as well |
| 13:41 | <annevk> | ah, I see, oh well, it doesn't realy matter as long as we keep a dictionary implementation |
| 13:41 | <Philip`> | (http://canvex.lazyilluminati.com/misc/parser/tokeniser.html uses a big entityNameMatch regexp, which sorts the names by descending length, but my C++ one uses a lexicographically-sorted table instead since I copied hsivonen's idea) |
| 13:47 | <annevk> | a \ exposes a bug in your JS tokenizer |
| 13:48 | <Philip`> | ? |
| 13:49 | <annevk> | it outputs \\ |
| 13:50 | <hsivonen> | aren't you supposed to escape \ in JSON? |
| 13:50 | <Philip`> | You are supposed to |
| 13:50 | <Philip`> | which is why it does :-) |
| 13:50 | <annevk> | oh |
| 13:50 | annevk | hides |
| 13:50 | <Philip`> | The "Serialised HTML" view gives a single \ |
| 14:08 | <grimeboy> | You know it'd be pretty interesting if HTMLAudioElements had an attribute of type string called waveform, or even better an attribute of type byte_array called waveform. |
| 14:10 | <grimeboy> | Actually javascript needs a ByteArray. |
| 14:10 | <Philip`> | For reading the waveform, or for altering it? |
| 14:11 | <annevk> | ES4 has a byte array |
| 14:11 | <grimeboy> | Both. |
| 14:11 | <annevk> | XMLHttpRequest level 2 is going to use it |
| 14:11 | <grimeboy> | Oh that's good. |
| 14:11 | <Philip`> | Byte arrays wouldn't be very useful for 16-bit audio |
| 14:12 | <grimeboy> | No, probably not. |
| 14:13 | <Philip`> | For just generating audio files dynamically, I guess you can already do audio.src = 'data:audio/wav;base64,...' |
| 14:14 | <grimeboy> | Oh right. That's a interesting idea. |
| 14:19 | <Philip`> | Are there specific cases for which it'd be useful to read the waveform? |
| 14:20 | <Philip`> | (I can't think of anything obvious that wouldn't be horribly slow to do in JavaScript...) |
| 14:31 | <grimeboy> | No, I suppose most things would be too slow (although javascript implementations are getting faster). I was thinking the traditional stuff, changing pitch, averaging with a sine wave, etc. etc. |
| 15:05 | <zcorpan> | annevk: the thread is about wrap=off specifically |
| 15:05 | <annevk> | does that map to soft? |
| 15:06 | <zcorpan> | submission-wise yes, rendering-wise no |
| 15:06 | <annevk> | oh, I see |
| 15:07 | <annevk> | spec doesn't seem to deal with invalid values |
| 15:08 | <annevk> | edited my reply |
| 15:09 | <zcorpan> | "For other attributes that contain invalid values" |
| 15:10 | <annevk> | so like soft |
| 21:50 | <Hixie> | annevk: IE supports draggable=""?? |
| 22:35 | <Xsss4hell> | hi |
| 22:35 | <zcorpan_> | hi |
| 22:35 | <Xsss4hell> | http://webforms2.org/ is offline |
| 22:35 | <Xsss4hell> | or are you just redesigning? |
| 22:36 | <zcorpan_> | probably just down temporarily |
| 22:36 | <Xsss4hell> | yep, hope it's back in some minutes =) |
| 22:37 | <Xsss4hell> | I'm developing a framework and wanted to use this nice xforms |
| 22:56 | <Xsss4hell> | which xpath and xforms frameworks do you recommend for clients having browser which do not support xforms and xpath |
| 22:56 | <Xsss4hell> | I'm talking about IE :P |
| 22:58 | <zcorpan_> | are there browsers that natively support xforms? |
| 22:59 | <zcorpan_> | gsnedders: your test case sucks ;) "FAIL" should be "This text should be striked out" |
| 23:00 | <zcorpan_> | gsnedders: or better yet, "This line should have a green background" along with background:lime |
| 23:01 | <zcorpan_> | and p { background:red } |
| 23:01 | <Philip`> | (Is it striked or struck? Or maybe it could be strike outed) |
| 23:03 | <zcorpan_> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21DOCTYPE%20html%3E%3Cstyle%3Ep%7Bbackground%3Ared%7D%23t%E91%5C%24t%7Bbackground%3Alime%7D%3C/style%3E%3Cp%20id%3D%22t%E91%24t%22%3EThis%20line%20should%20have%20a%20green%20background. |
| 23:06 | <gsnedders> | zcorpan_: meh. throwing stuff together while half asleep :P |
| 23:06 | <jgraham> | annevk: I think we will have to at least look at the issue (SVG+etc. in text/html) for HTML 5. I have no idea what the outcome will be. |
| 23:06 | <zcorpan_> | gsnedders: fair enough :) |
| 23:06 | <gsnedders> | zcorpan_: and also in the middle of doing other stuff |
| 23:18 | <Xsss4hell> | no script that enabled xpath and xforms crossbrowser? |
| 23:24 | <zcorpan_> | Xsss4hell: i don't know of any. there is an xforms player plugin for ie and an extension or something for firefox, though, iirc |
| 23:24 | <zcorpan_> | Xsss4hell: there are however scripted implementations of web forms 2.0 |
| 23:25 | <zcorpan_> | Xsss4hell: and opera supports wf2 natively |
| 23:35 | <Xsss4hell> | I've found some xpath and xforms player but thought you know better, however thankx |
| 23:35 | <Xsss4hell> | sf.net^^ |
| 23:55 | <Hixie> | only 772 e-mails to go |