| 06:43 | <hsivonen> | Re: <legend>: I think we should just mint a new tag name--even if ugly. For example, <figcaption>. |
| 07:16 | <jruderman> | <fignetwon> |
| 10:53 | <yecril71> | If you put an immediate script after a deferred CSS, |
| 10:53 | <yecril71> | the script need not see the CSS. |
| 10:53 | <yecril71> | (and CSS can be deferred without warning). |
| 10:54 | <yecril71> | In order to provide for such a dependency, |
| 10:54 | <yecril71> | you can put the CSS-dependent code in the style element�s load handler. |
| 10:58 | <yecril71> | Why is createScript more appropriate than createElement("script")? |
| 11:04 | <Lachy> | yecril71, what are you talking about? |
| 11:05 | <annevk5> | he doesn't post the mailing list but instead comments here |
| 11:06 | <Lachy> | it would be nice if he gave some context, like mentioning the thread or something |
| 11:06 | <jgraham> | Maybe he just didn't like the tumbleweed |
| 11:08 | <yecril71> | We do not have tumbleweed in Poland. |
| 11:09 | <yecril71> | The thread is Re: [whatwg] defer on style, depends |
| 11:21 | <yecril71> | Unstyled content is ugly/unreadable in the following cases: |
| 11:21 | <yecril71> | * when the text contains formulas that cannot be displayed otherwise, |
| 11:22 | <yecril71> | * when the content uses custom fonts (e.g. when the language it is in is not supported by contemporary operating systems), |
| 11:23 | <yecril71> | * when it uses CSS for semantic images (bad, but necessary because MSIE is broken) |
| 11:23 | zcorpan | looks at http://html5.validator.nu/?doc=http%3A%2F%2Fwww.webforum.nu%2F and wonders whether the output would be more useful if the "downplayed errors" were implemented |
| 11:24 | <virtuelv> | hm |
| 11:24 | <virtuelv> | "Use alt text infotips to describe graphics." |
| 11:24 | <yecril71> | * when the author is HTML-incompetent (bad). |
| 11:24 | <virtuelv> | from MS HiG: http://msdn.microsoft.com/en-us/library/bb545462.aspx?ppud=4 |
| 11:26 | <yecril71> | The HTML5 specification is an example of a document that is actually better viewed without CSS. |
| 11:26 | <yecril71> | (At least, in MSIE). |
| 11:29 | <zcorpan> | gsnedders: http://validator.nu/?doc=http%3A%2F%2Fsimon.html5.org%2Fspecs%2Fxml-stylesheet5 could you fix this? :P |
| 11:32 | <zcorpan> | Lachy: in the html5 reference it might be useful to list event handler attributes that are likely to be useful specifically for a certain element (e.g. those related to media elements) |
| 11:37 | <zcorpan> | ie8 finally has a menu item to disable stylesheets |
| 11:39 | <Lachy> | zcorpan, which attributes specifically? |
| 11:40 | <Lachy> | zcorpan, please file a bug or send mail http://www.w3.org/Bugs/Public/enter_bug.cgi?product=HTML%20WG&component=Developer%27s%20Guide |
| 11:46 | <yecril71> | MSIE7 developer toolbar allows disabling CSS as well |
| 11:49 | <Lachy> | Do these events have associated on[event]="" content attributes? http://www.whatwg.org/specs/web-apps/current-work/#mediaevents |
| 11:49 | <annevk5> | yes |
| 11:49 | <Lachy> | I can't find them in the spec |
| 11:50 | <annevk5> | soon in a HTML 5 spec near you and such |
| 11:50 | <Lachy> | zcorpan, were they the attributes you're talking about? |
| 11:51 | <Lachy> | if so, then they will get included in the html5 reference once Hixie includes them in the spec. |
| 12:11 | <zcorpan> | Lachy: http://www.w3.org/Bugs/Public/show_bug.cgi?id=6475 |
| 12:12 | <zcorpan> | Lachy: or you could take the other approach i thought of |
| 12:12 | <zcorpan> | i.e. listing the events that are fired |
| 12:16 | <Lachy> | zcorpan, what's the other approach you thought of? |
| 12:17 | <Lachy> | oh, do you mean "listing the events that are fired" is the other approach? |
| 12:18 | <zcorpan> | yes |
| 12:19 | <annevk5> | makes sense for HTML5 itself as well I think |
| 12:20 | <annevk5> | listing events that are dispatched |
| 12:20 | <Lachy> | if the spec lists those in the summary boxes, then that would be easier for my script to just extract them all |
| 12:41 | <hsivonen> | what's the 0xFDD0 to 0xFDEF range in Unicode for? |
| 12:42 | <hsivonen> | other than eye of the basilisk, of course |
| 12:43 | <hsivonen> | fun, fun, fun. 0xFDD0 to 0xFDEF is allowed in XML 1.0 but gets special treatment in HTML5 NCR expansion |
| 13:09 | <jgraham> | hsivonen: I guess you already know this but the Unicode standard is pretty vauge about the purpose of that range. It just says they are "non character code points" that happen to be inside a block of arabic characters for historic reasons |
| 13:10 | <jgraham> | It seems like XML is wrong per unicode if it allows these characters: |
| 13:10 | <jgraham> | "Applications are free to use any of these noncharacter code points internally but should |
| 13:10 | <jgraham> | never attempt to exchange them |
| 13:10 | <jgraham> | " |
| 13:11 | <zcorpan> | something that xml 1.0 6th ed should fix? |
| 13:11 | <hsivonen> | zcorpan: the XML Core WG has knowingly not fixed this |
| 13:11 | <hsivonen> | zcorpan: but has instead put an informative note about the state of affairs in XML |
| 13:12 | <hsivonen> | In my opinion, general-purpose specs like XML shouldn't try to limit data flow except for U+0000 |
| 13:13 | <hsivonen> | that is, I don't see broadening the set of ill-formed streams solving Real Problems |
| 13:19 | <takkaria> | heh, the issues graph hsays that Hixie will be finished with email as of this Christmas |
| 13:19 | <jgraham> | Does anyone know what a * means in the Simple_Uppercase_Mapping field of UnicodeData.txt? |
| 13:20 | <jgraham> | Or am I miscountin again... |
| 13:21 | <jgraham> | Oh, I think I can't count |
| 13:37 | <gsnedders> | zcorpan: libxml serializer bug, I think. Using html5lib and it is fine |
| 13:38 | jgraham | promises to upgrade pms.net "Real Soon Now" |
| 13:40 | <gsnedders> | jgraham: What does it use? What parser and serializer? |
| 13:41 | <jgraham> | gsnedders: I has a whole pile of "advanced options" basically all the ones that anolis supports from the command line |
| 13:41 | <annevk5> | XML does not do Unicode Normalization either... |
| 13:43 | <hsivonen> | annevk5: the problem statement for the normalization thread should probably be written in terms of ability to type natural-language words instead of defining the problem in terms of the concept of normalization |
| 13:43 | <hsivonen> | for example, the fi ligature or the ohm sign are pretty irrelevant to enabling other natural languages on the same level as English |
| 13:45 | <annevk5> | I think I'll wait for the result of that wiki project and then see where this is going |
| 13:46 | <hsivonen> | I don't want to get into a wiki edit war. I guess I'll add an alternative problem statement to the wiki alongside the current one at some point. |
| 13:46 | <annevk5> | and meanwhile object to adding anything regarding it to CSS specifications may someone suggest that (fantasai did raise some issues with proposed solutions I do not agree with) |
| 14:22 | <Dashiva> | The listserv needs better AI. It should recognize that it's received the same message to both @lists.whatwg.org and @whatwg.org. |
| 14:24 | <Lachy> | people should just stop sending to @lists.whatwg.org, and use @whatwg.org only |
| 14:24 | <Dashiva> | That would be nice, but we know how well educating people works ;) |
| 14:25 | <Lachy> | of course, the education system works perfectly. So what's the problem? ;-) |
| 14:27 | <Lachy> | which mail in particular was received twice? I don't see any |
| 14:54 | <beowulf> | whatwg types, do you think it's important for students studying web design to be able to write html to standard? |
| 14:55 | <annevk5> | sort of depends on whether they actually wanna write code or just design, no? |
| 14:55 | <jgraham> | I don't really understand what "studying web design" means |
| 14:56 | <jgraham> | Like, practially what does such a course cover |
| 14:57 | <Dashiva> | Lachy: Maybe your client removes duplicates. It was smylers' on style |
| 15:45 | <hsivonen> | annevk5: did you see my alternative normalization problem statement? did it make sense? |
| 15:46 | <annevk5> | yes and yes |
| 15:46 | <hsivonen> | good |
| 15:47 | <annevk5> | I would love to hear actual developer feedback on this issue rather than theoretical arguments |
| 15:48 | <hsivonen> | I would love to hear actual Vietnamese etc. Web developer feedback |
| 15:48 | <annevk5> | indeed, it's not like the internet is brand new there although it is used less most likely |
| 15:50 | <annevk5> | people at work said that they never heard this was a problem for e.g. Chinese and Japanese |
| 15:50 | <hsivonen> | annevk5: this problem doesn't apply to Chinese and Japanese to any noticeable extent |
| 15:51 | <annevk5> | k, I wonder why Richard lists them then |
| 15:51 | <hsivonen> | (even though it is possible to dig up a case where you could construct a case that applies to Chinese; see example given by Rob Burns) |
| 15:52 | <hsivonen> | In theory, the issue applies to European languages and Korean all the time, but in practice the input methods normalize, so it's not a problem in practice |
| 15:53 | <hsivonen> | aside: the European and Korean markets would reject using NFD for interchange so hard, that it's not even debatable to use anything but NFC if one wants one normalization form to rule them all |
| 15:54 | <annevk5> | what does for Chinese and Japanese, does that go for Arabic as well? |
| 15:55 | <jgraham> | hsivonen: I thought it applied to Japanese because of emphasis dots or something. Although I don't know why one would put an emphasis dot in an identifier |
| 15:55 | <jgraham> | Oh, wait there's no NFC |
| 15:55 | <jgraham> | for that |
| 15:55 | <jgraham> | ignore me |
| 15:55 | <hsivonen> | annevk5: I haven't studied the applicability of the issue to Arabic vowels |
| 15:56 | <hsivonen> | annevk5: but Arabic--in theory--has presentation forms, but then presentation forms equivalence is unaddressed for English, too |
| 15:58 | <jgraham> | hsivonen: Do you know why unicode has seperate codepoints corresponding to presentation forms? That was news to me until recently and it seems rather insane |
| 15:59 | <hsivonen> | jgraham: presentation forms that have distinct code points in legacy encodings (such as MacRoman for fi and fl ligatures) have distinct code points in Unicode |
| 15:59 | <jgraham> | hsivonen: OK, I guessed it would be something like that. Is it now considered a mistake? |
| 15:59 | <jgraham> | (not that that helps of course) |
| 15:59 | <hsivonen> | jgraham: by whom? :-) |
| 16:00 | <jgraham> | hsivonen: Popular opinion amongst unicode people :) |
| 16:00 | <hsivonen> | jgraham: dunno |
| 16:03 | <annevk5> | sounds like a mistake |
| 16:03 | <hsivonen> | annevk5: depends on your round trippability requirements |
| 16:03 | <annevk5> | fair point |
| 16:04 | <hsivonen> | today, of course, there's less need to round trip, since one can pretty much always output UTF-8 |
| 16:04 | jgraham | wonders if "the characters are converted one by one" in the ECMAScript spec is intended to mean "the characters are converted without reference to conditional mappings in SpecialCasings.txt" |
| 16:06 | <jgraham> | Which seems like a weird optimization because it only applies to one character in toLowerCase, none in toUpperCase, but breaks about half the time in toLocaleLowerCase in the cases where that function makes a difference |
| 16:07 | <jgraham> | s/SpecialCasings/SpecialCasing/ |
| 16:07 | <jgraham> | and I guess s/breaks/produces incorrect results/ |
| 16:35 | <jgraham> | Hmm, there are more cases where it would make a difference to do things right |
| 16:43 | <jgraham> | (but they have to do with normalization) |
| 18:07 | <yecril71> | MSIE and Firefox support deferring scripts now. |
| 18:07 | <yecril71> | I would not regard these as a "minority of browsers". |
| 18:07 | <jcranmer> | IE 5, 6, 7, or 8? |
| 18:10 | <yecril71> | I think all of them, although I am sure of 6+ |
| 18:10 | <yecril71> | deferring is MS�s invention. |
| 18:11 | <Lachy> | yecril71, defer was in HTML4 |
| 18:12 | <yecril71> | (indeed, better support for defer was the reason I joined WHATWG) |
| 18:12 | <Lachy> | that seems like quite a small reason |
| 18:13 | yecril71 | admits |
| 18:14 | <yecril71> | Hixie�s invited me from Bugzilla |
| 20:05 | <gsnedders> | Goddamn you Python and your broken indecision about Unicode! |
| 20:12 | <jwalden> | holy splitmeisters Batman! |
| 21:04 | <yecril71> | Python is only a tool, and its only merit is that it is fashionable. |
| 21:13 | <yecril71> | I think two-way bandwidth negotiation for streaming media would be a good thing. |
| 21:14 | <yecril71> | But I do not think this has anything to do with HTML. |
| 21:45 | Philip` | notes that the BBC iPlayer has a very simple but seemingly perfectly adequate bandwidth negotiation technology: there's a button that says "Play high quality" (with a tooltip saying it requires "a fast internet connection, at least 1Mbps") |
| 21:48 | gsnedders | wonders whether the F1 will be on iPlayer… |
| 23:32 | jwalden | wonders if <input type=checkbox indeterminate> has been proposed yet |
| 23:32 | <jruderman> | annevk5: i heard that opera has some kind of protection against internet sites CSRFing intranet sites. are you guys willing to share a description of your algorithm and your experience with it? |
| 23:34 | <Philip`> | jwalden: It has been proposed, and then added to the spec |
| 23:34 | <jwalden> | hm |
| 23:34 | <Philip`> | jwalden: (See http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#checkbox-state ) |
| 23:34 | <Philip`> | jwalden: Oh, except that's only a DOM attribute, not a content attribute, seemingly |
| 23:35 | <Philip`> | jwalden: but it's close enough :-) |
| 23:37 | <jwalden> | Philip`: I was specifically referring to the content attribute; it's come up in discussion of handling indeterminate in gecko, where a reviewer asked for a test to use static markup rather than dynamically changing it |
| 23:37 | jwalden | shoots the attribute dual-definition |
| 23:37 | <Philip`> | jwalden: Ah, right |
| 23:38 | <jwalden> | and as far as I could tell from those various discussions, it was just "there isn't one" rather than "this is why there isn't one" |
| 23:39 | <Philip`> | IE doesn't support it as a content attribute |
| 23:42 | <Hixie> | the spec just does what IE does |
| 23:42 | <jwalden> | sure, but when has that stopped anyone? |
| 23:42 | <Hixie> | (which by the way is pretty ridiculous) |
| 23:42 | <Hixie> | (e.g. it's actually a two-state checkbox even with indeterminate) |
| 23:42 | <Hixie> | (not a real three-state checkbox) |
| 23:43 | <Hixie> | (the indeterminate flag just hides the state in the UI) |
| 23:44 | <jwalden> | I wonder how much form-submission code would get broken by serializing as name=indeterminate |
| 23:44 | <jwalden> | if any |
| 23:45 | <Hixie> | my intent is to not add new features if i can help it |
| 23:45 | <Hixie> | we have too much new stuff waiting for implementation already |
| 23:45 | <jwalden> | this is hardly that featureful, just bringing markup up to par with DOM properties |
| 23:46 | <Hixie> | there are literally hundreds of things on this scale that people are asking for |
| 23:52 | <Hixie> | hasn't been much whining recently |
| 23:52 | <Hixie> | what's that about |