| 02:38 | <MikeSmith> | Hixie: about http://www.w3.org/Bugs/Public/show_bug.cgi?id=9198 |
| 02:39 | <MikeSmith> | since hspace and vspace are already now allowed on embed, I assume that bug must be asking that they be explicitly listed in the obsolete-and-nonconforming section |
| 07:00 | Hixie | wonders what the chart on http://blogs.msdn.com/ie/archive/2010/03/05/ie8-smartscreen-filter-protecting-users-at-internet-scale.aspx shows |
| 07:05 | <MikeSmith> | Hixie: "mean block rate for socially engineered software" |
| 07:05 | <MikeSmith> | s/software/malware/ |
| 07:06 | <MikeSmith> | (in the full PDF report that's linked to there) |
| 07:10 | <MikeSmith> | It might help if they actually used something closer to commonly used terms |
| 07:11 | <MikeSmith> | since as far as I can see it appears to be comparing the anti-phishing mechanisms that various browsers provide |
| 07:15 | <nessy> | and what do the percentages mean? |
| 07:15 | <nessy> | number of attacks captured? |
| 07:15 | <MikeSmith> | nessy: yeah, seems so |
| 07:16 | <nessy> | they should compare the absolute number of attacks that succeeded, that would be more interesting :) |
| 07:16 | <othermaciej> | I've seen the similar study published before and it seemed questionable to me |
| 07:16 | <othermaciej> | 1) they don't give enough information to reproduce their results (neither original data, nor enough detail of the methodology) |
| 07:18 | <othermaciej> | 2) what they do say sounded like there was a lot of arbitrary fiddling with the original test sites (e.g. to remove ones that exploit security bugs in some way other than social engineering, which seems pretty point-missing) |
| 07:18 | <othermaciej> | 3) it's not clear if their data source for what sites contain malware in the first place is independent from Microsoft's |
| 07:19 | <othermaciej> | I would also say it's very suspicious that Firefox, Safari and Chrome get such different results, considering they all use Google's malware/phishing data |
| 07:40 | <MikeSmith> | othermaciej: hmm, updated my Webkit and now I get "Nightly builds of WebKit are not supported on Mac OS X 10.5 at this time" |
| 07:40 | <othermaciej> | MikeSmith: that's a surprise to me |
| 07:42 | <othermaciej> | MikeSmith: it's also a surprise to the guy who makes the nightlies, so it's probably a bug |
| 07:42 | <MikeSmith> | ah, OK |
| 07:42 | <othermaciej> | MikeSmith: does it work if you relaunch it? |
| 07:43 | <othermaciej> | I'm told that alert sometimes pops up incorrectly |
| 07:43 | <MikeSmith> | doesn't work even if I relaunch it |
| 07:43 | <MikeSmith> | I tried a few times now |
| 07:44 | <MikeSmith> | fwiw, Get Info shows r55610 |
| 08:01 | <MikeSmith> | othermaciej: btw, can you advise me on how best to proceed with discussion about getting the author view of the HTML5 spec published as a WD? |
| 08:02 | <MikeSmith> | Hixie: btw, are you supportive of publishing the static author view of the spec as a WD? |
| 08:02 | <MikeSmith> | http://dev.w3.org/html5/spec-author-view/ |
| 08:02 | <othermaciej> | MikeSmith: if the editor proposes it, then the chairs would likely put an FPWD resolution before the group |
| 08:02 | <othermaciej> | I believe it meets the threshold of being a bona fide collaborative product of the WG |
| 08:03 | <othermaciej> | and I believe it is reasonably in scope |
| 08:03 | <MikeSmith> | OK, thanks |
| 08:03 | <MikeSmith> | so I guess will propose to Hixie that he propose it |
| 08:03 | <othermaciej> | I did notice that the author view radio button is now available on the TR page |
| 08:03 | <MikeSmith> | yeah |
| 08:03 | <MikeSmith> | let's please not make a lot of noise about that |
| 08:04 | <othermaciej> | MikeSmith: btw, my preference would be to start the publication cycle about 2 months from now |
| 08:04 | <MikeSmith> | no one has ever explicitly told me that we can't have JS in docs in TR |
| 08:04 | <othermaciej> | it took about 1 month from the time the publication CfC was posted to the time we published |
| 08:04 | <MikeSmith> | othermaciej: works for me |
| 08:04 | <othermaciej> | so we have to start the CfC in 2 months to actually satisfy the heartbeat requirement |
| 08:04 | <MikeSmith> | yeah |
| 08:04 | <othermaciej> | if there were additional drafts ready by then, that would be cool |
| 08:05 | <othermaciej> | also if we publish WDs more often then hopefully it can be less dramatic |
| 08:05 | <MikeSmith> | yes |
| 08:05 | <MikeSmith> | so that means restarting WD discussion in early May, publishing in June |
| 08:06 | <MikeSmith> | it would good to get new drafts out before the July/August holiday period |
| 08:06 | <MikeSmith> | when a lot of people tend to be away for weeks at a time |
| 08:07 | <Hixie> | MikeSmith: i'm happy for it to be there, though i think if we publish it we should probably do it as a subcomponent of the HTML5 spec, not a separate /TR/ deliverable |
| 08:07 | <Hixie> | MikeSmith: probably should make it clear that it's non-normative, too |
| 08:07 | <othermaciej> | Hixie: how would you do it as a subcomponent? separate link in the table of contents? |
| 08:11 | <othermaciej> | MikeSmith: bdash suggests "download a fresh build from nightly.webkit.org, and to save the bad build and file a bug report with it" |
| 08:12 | <Hixie> | yeah, i guess |
| 08:12 | <Hixie> | well, no |
| 08:12 | <Hixie> | more like the same way we do the multipage version |
| 08:12 | <Hixie> | there's a w3c convention for this kind of thing |
| 08:13 | <Hixie> | links to pdf versions, multipage versions, etc |
| 08:14 | <MikeSmith> | ah yeah |
| 08:14 | <MikeSmith> | good point |
| 08:14 | <MikeSmith> | we can just treat it as a variant of the full spec |
| 08:14 | <othermaciej> | ah, alternate non-normative formats |
| 08:18 | <boblet> | MikeSmith: re: http://dev.w3.org/html5/spec-author-view/ what’s up with the double asterisk overlapping “call” in “Status: last call for comments” |
| 08:18 | <boblet> | eg http://dev.w3.org/html5/spec-author-view/sections.html#the-article-element |
| 08:19 | <boblet> | looks like generated content, but I can’t see from where |
| 08:20 | <MikeSmith> | boblet: no idea |
| 08:21 | <MikeSmith> | some borkedness in the CSS stylesheet I'll need to unwind |
| 08:21 | <boblet> | heh |
| 08:24 | <Hixie> | boblet: what browser? |
| 08:24 | <MikeSmith> | othermaciej: OK, grabbed a fresh build and it's working fine |
| 08:24 | <othermaciej> | MikeSmith: woot |
| 08:25 | <MikeSmith> | othermaciej: so what should I attache to the bug report? |
| 08:25 | <MikeSmith> | zip up the WebKit.app ? |
| 08:25 | <boblet> | Hixie: seeing those asterisks in Chrome and FF latest for Mac. Only me? |
| 08:25 | <Hixie> | boblet: does it disappear if you hit command++/command+- ? |
| 08:26 | <boblet> | nope. changing body font to serif changes position slightly though |
| 08:26 | <boblet> | (moves it to end of “call”) |
| 08:27 | <boblet> | holler if you want screenshots |
| 08:27 | <Hixie> | boblet: sounds like a browser bug to me -- misplaced ::before or ::after from a class="XXX" element. |
| 08:28 | <Hixie> | odd that it doesn't move when you resize though |
| 08:28 | <MikeSmith> | .XXX:before, .XXX:after { content: " ** "; position: absolute; left: 0; width: 8em; text-align: right; } |
| 08:29 | <boblet> | MikeSmith: there you go. Pity inspector & Firebug don’t show generated content (& make it hard to access eg hover state CSS) |
| 08:29 | <MikeSmith> | indeed |
| 08:29 | <MikeSmith> | anyway, I just checked in a fiew |
| 08:29 | <MikeSmith> | fix |
| 08:30 | <MikeSmith> | eagle eye |
| 08:30 | <boblet> | happy to help ;-) |
| 08:30 | MikeSmith | thinks boblet must read through specs with a jeweler's loupe |
| 08:31 | <boblet> | “hey, designers *are* good for something!” |
| 08:31 | <MikeSmith> | heh |
| 08:31 | <Hixie> | MikeSmith: what was the bug? (what did you change?) |
| 08:34 | <MikeSmith> | Hixie: I made a copy of the http://www.whatwg.org/style/specification stylesheet |
| 08:35 | <MikeSmith> | and have I that document referencing it |
| 08:35 | <MikeSmith> | I can't quite remember why, now |
| 08:35 | <MikeSmith> | but that's what it's doing |
| 08:35 | <MikeSmith> | and what I did was just to comment out that part |
| 08:35 | <MikeSmith> | .XXX:before, .XXX:after { content: " ** "; position: absolute; left: 0; width: 8em; text-align: right; } |
| 08:38 | <Hixie> | neither of those should be necessary :-) |
| 08:38 | <boblet> | maybe someone who really really liked Markdown wrote the CSS? |
| 08:39 | <MikeSmith> | I blame the CSS gremlins |
| 08:42 | <Hixie> | boblet: i wrote that css, but it shouldn't be doing what you describe |
| 08:42 | <Hixie> | boblet: hence why i think it's a browser bug |
| 08:44 | <Creap> | is there any input which can represent a time including seconds? |
| 08:46 | <boblet> | Hixie: what was the effect you wanted? It seems like it’s putting ** 8em from the left inside .XXX, and that happens to be about where class is |
| 08:47 | <zcorpan> | Creap: "A time consists of a specific time with no time-zone information, consisting of an hour, a minute, a second, and a fraction of a second." |
| 08:48 | <zcorpan> | Creap: from the spec on <input type=time> |
| 08:49 | <Creap> | ok, I was confused by http://www.w3.org/TR/html-markup/input.time.html#input.time + Opera's implementation lacking seconds |
| 08:51 | <Hixie> | boblet: oh, i thought you meant it was nowhere near anything that should have had the stars |
| 08:51 | <Hixie> | Creap: make sure to set step=1 |
| 08:52 | <Hixie> | boblet: it's supposed to attract attention to the issues |
| 08:52 | <boblet> | Hixie: the ** appear inside a paragraph with .XXX, so it’s as expected |
| 08:52 | <Hixie> | boblet: ah ok |
| 08:53 | <Creap> | ah. |
| 08:54 | <zcorpan> | Creap: could you file a bug about opera's impl? |
| 08:55 | <Creap> | should it include seconds by default? using step=1 as hixie suggested makes it show seconds |
| 08:55 | <boblet> | Hixie: if you were wanting ** before and after, I think you might need to define :before and :after separately |
| 08:58 | <mut> | do i have to use .closePath? or not? |
| 09:09 | <Hixie> | boblet: why? |
| 09:10 | <Hixie> | Creap: step=60 is the default, so it hides seconds by default |
| 09:10 | <Creap> | ok |
| 09:11 | <Creap> | is datetime's step also specified in seconds? |
| 09:11 | <Hixie> | iirc, yes |
| 09:12 | <Hixie> | ok i'm outta here. g'night all. |
| 09:12 | <MikeSmith> | おつかれ |
| 09:16 | <zcorpan> | Creap: step="any" should make it show seconds |
| 09:18 | MikeSmith | wonders if there's a dev.opera.com article on forms features |
| 09:18 | <zcorpan> | http://dev.opera.com/articles/view/improve-your-forms-using-html5/ |
| 09:19 | <MikeSmith> | hmm |
| 09:19 | <zcorpan> | it'd be nice with an article with more coverage |
| 09:19 | <MikeSmith> | yeah |
| 09:19 | <MikeSmith> | http://dev.opera.com/articles/tags/forms/ :( |
| 09:28 | <MikeSmith> | hmm, we are really going to need some how-to guides about the new input types and other forms features |
| 09:29 | <MikeSmith> | this stuff is not especially intuitive |
| 09:48 | <annevk> | http://www.w3.org/People/Jaffe/ |
| 10:00 | <knowtheory> | yeh, new ceo eh annevk? |
| 10:00 | <knowtheory> | and his first post: http://www.w3.org/QA/2010/03/w3c_ceo_blog_first_posting_mar.html |
| 10:30 | <hsivonen> | does ie8 smartscreen differ from the phishing and malware blacklist features of other browsers in terms of features? or is the difference microsoft's server side instead of google's? |
| 10:35 | <othermaciej> | they have some purely client-side heuristics too, I believe |
| 10:40 | <knowtheory> | othermaciej: what time zone are you in? o_O |
| 10:40 | <othermaciej> | "other" |
| 10:41 | <knowtheory> | heh, ah yes, that one, i know it well. |
| 10:41 | <knowtheory> | (it's awkward living in EST, and working w/ people in GMT and PST) |
| 10:44 | <zcorpan> | http://www.w3.org/WAI/PF/src/role-attribute-src.html |
| 10:48 | <annevk> | the examples in that document seem somewhat misguided |
| 11:18 | <MikeSmith> | does Webkit already have some mechanism for exposing orientiation/acceleromerter events to Web applications? |
| 11:18 | <MikeSmith> | was reading the new Orientation Event spec http://dev.w3.org/geo/api/spec-source-orientation.html |
| 11:19 | <MikeSmith> | and noticed that it informatively references https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsIDOMOrientationEvent |
| 11:19 | <MikeSmith> | and I remember recently seeing a guy do a File API demo in Mozilla that appeared to be reacting to changes in orientation of his Macbook |
| 11:28 | <knowtheory> | hah, that's cool :D |
| 11:33 | <MikeSmith> | cool also to see that work seems to have started on implemented CSS3 Paged Media in Webkit - https://bugs.webkit.org/show_bug.cgi?id=15548 |
| 13:00 | <zcorpan> | hsivonen: "but it looks like once it reads a conditional comment, it's too late to change X-UA-Compatible." -- http://www.sitepoint.com/forums/showthread.php?t=663679 |
| 13:12 | <hsivonen> | zcorpan: Yeah, I'm aware that conditional comments (like scripts) make later X-UA-Compatible ineffective. I just haven't gotten around to updating the flowchart. |
| 13:24 | <zcorpan> | ok |
| 13:40 | <asmodai> | mmm |
| 13:41 | <asmodai> | So why doesn't HTML 5 include ruby markup in the spec? :) (per Ishida's email on www-int) |
| 13:41 | <annevk> | it doesn't? |
| 13:42 | <asmodai> | Hmm, apparently not |
| 13:43 | <myakura> | It does http://www.whatwg.org/html5#the-ruby |
| 13:43 | <asmodai> | hmmm |
| 13:43 | <asmodai> | yeah, just looking at that |
| 13:43 | <annevk> | http://lists.w3.org/Archives/Public/www-international/2010JanMar/0107.html seems Richard is asking about complex ruby |
| 13:43 | <annevk> | which was deliberately left out |
| 13:43 | <asmodai> | annevk: there's complex? |
| 13:44 | asmodai | thought there was only 1 Ruby spec |
| 13:44 | <annevk> | see http://www.w3.org/TR/2001/REC-ruby-20010531/#complex |
| 13:44 | <annevk> | asmodai, well yeah, but nobody implements /TR/ruby/ |
| 13:45 | <asmodai> | Mmm, have never seen the complex case being used for Asian languages. |
| 13:45 | <asmodai> | annevk: Aside from the addon for Firefox? |
| 13:45 | <asmodai> | annevk: XHTML Ruby |
| 13:48 | <annevk> | asmodai, I doubt that plugin implements it correctly |
| 13:48 | <annevk> | but yeah |
| 13:48 | <asmodai> | annevk: Actually, it passes all tests IIRC |
| 13:49 | <asmodai> | annevk: http://www.w3.org/International/tests/results/results-ruby-markup-2 |
| 13:50 | <asmodai> | bit older version of the addon |
| 14:02 | <MikeSmith> | http://lists.w3.org/Archives/Public/www-international/2010JanMar/0107.html |
| 14:18 | <annevk> | asmodai, if it was done correctly it would've made it into Gecko by now |
| 14:28 | <hsivonen> | annevk, asmodai: addons don't go deep into layout and add CSS box types. proper Ruby support needs support from the CSS formatter, IIRC. |
| 14:42 | <annevk> | hsivonen, right |
| 15:07 | <asmodai> | hsivonen: I know nothing of that. :) |
| 15:07 | <boblet> | did anything come of using @datetime on <article>? I’m guessing better to not have as an invisible attribute, but… |
| 15:07 | <asmodai> | hsivonen: So I'll take your word for it. |
| 15:09 | <boblet> | huh. datetime isn’t mentioned under the-article-element and isn’t in global attribs, so I guess no |
| 15:12 | <MikeSmith> | boblet: I seem to remember it being there for a while, then being removed |
| 15:12 | <MikeSmith> | but I may have imagined it all |
| 15:12 | <boblet> | I definitely remember it being discussed for blog posts, but yeah not there now |
| 15:14 | <Philip`> | I thought it was called pubdate now |
| 15:14 | <mr_danie1> | is the following sentence in the book 'div into html5' (http://diveintohtml5.org/) book really true: |
| 15:14 | <mr_danie1> | ...The HTTP header is the preferred method, and it overrides the <meta> tag if present.... |
| 15:15 | <mr_danie1> | you can find it in this page: http://diveintohtml5.org/semantics.html#encoding |
| 15:15 | <mr_danie1> | I thought the reason why the <meta charset=...> tag is available is because most authores CANNOT set the http content-type header |
| 15:16 | <mr_danie1> | but when the http content-type header, which could be wrong', overwrites any authors attempt to alter the charset, the <meta charset=...> wouldn't make sense |
| 15:17 | <boblet> | Philip`: aah nice, thanks |
| 15:17 | <mr_danie1> | I think this must be a typo in the book. can someone confirm this? |
| 15:17 | <boblet> | mr_danie1: I was under the impression that http header > meta charset |
| 15:18 | <workmad3> | mr_danie1: I think the book is correct |
| 15:18 | <workmad3> | http header outranks the meta charset |
| 15:18 | <Philip`> | http://www.whatwg.org/specs/web-apps/current-work/multipage/parsing.html#determining-the-character-encoding |
| 15:18 | <boblet> | mr_danie1: http://lists.w3.org/Archives/Public/www-validator/2008Mar/0024.html |
| 15:18 | <boblet> | heh |
| 15:18 | <Philip`> | "1. If the transport layer specifies an encoding, and it is supported, return that encoding with the confidence certain, and abort these steps." |
| 15:19 | <Philip`> | (where HTTP is a transport layer, and specifies encodings via Content-Type) |
| 15:23 | <workmad3> | mr_danie1: in the case where the server is serving data that it doesn't know the content type for, it should omit the content-type header completely I believe |
| 15:23 | <workmad3> | rather than send a false type that will be taken as exact |
| 15:24 | <mr_danie1> | I think meta charset > http header would be better, for example: the server sets content-type:charset=utf-8, but the author sets <meta charset=iso-... |
| 15:24 | <mr_danie1> | and when the http header, the content will be displayed wrong, because the content is iso-... |
| 15:25 | <mr_danie1> | ...http header WIN, the... |
| 15:25 | <Philip`> | mr_danie1: Can't do that because it would be incompatible with all current browsers |
| 15:25 | <workmad3> | mr_danie1: if the server is sending an incorrect content type, the server has a bug |
| 15:25 | <Philip`> | and probably incompatible with lots of current pages |
| 15:26 | <workmad3> | or is configured incorrectly... either way, it's not a problem with the standard |
| 15:26 | <Philip`> | You should always use UTF-8 anyway :-) |
| 15:26 | <mr_danie1> | ok, so html5 must use this policy because of its 'incremental html improvement' approach not to break the current web |
| 15:26 | <mr_danie1> | workmad3: true, then the server has a problem |
| 15:27 | <workmad3> | also, I believe in a lot of cases, it's the <meta charset= that is incorrect, because it was set on old content that has since been re-encoded |
| 15:27 | <mr_danie1> | Philip`: true, utf-8 is my favourite; it hate encoding issues, especially when I work in a team with lot of people |
| 15:27 | <Philip`> | mr_danie1: Yes, and also because it's probably better for the server to be authoritative |
| 15:28 | <workmad3> | and (checking the wiki page on http encodings) it looks like <meta> content types should be used by the server, not the browser |
| 15:28 | <Philip`> | You already have to trust the server to tell you the content is text/html rather than image/png or whatever, so it'd be odd if you trusted it to say the "content-type: text/html" part but not the "; charset=utf-8" part |
| 15:29 | <Philip`> | workmad3: ? |
| 15:29 | <Philip`> | Servers shouldn't be parsing HTML |
| 15:29 | <workmad3> | 'A known misconception about <meta http-equiv="Content-Type"> is that meta element is intended to be interpreted directly by a browser, like an ordinary HTML tag. According to WWW Consortium, it helps HTTP server[1] to generate some headers when it serves the document.' |
| 15:30 | <workmad3> | that said, it's a wiki page... it could easily be incorrect :) |
| 15:30 | <Philip`> | I assume that was the original intention, hence it being called "http-equiv" and being equivalent to HTTP headers, but that's crazy and not how it works today |
| 15:31 | <workmad3> | it does seem to gel with the description here as well though: http://www.w3.org/TR/html401/struct/global.html#edef-META |
| 15:31 | <Philip`> | Indeed, but HTML4 is crazy and doesn't reflect reality either |
| 15:32 | <workmad3> | heh :) |
| 15:37 | <Dashiva> | Imagine how fun it would be if every web server had its own HTML parser |
| 15:38 | <workmad3> | Dashiva: how about if web servers sniffed the browser types and rewrote the HTML they were serving to be compatible? :D |
| 15:39 | <Philip`> | Most web pages are generated dynamically and all the headers are output before any content, so it wouldn't even be possible to parse it and add headers |
| 15:41 | <asmodai> | annevk: Can you elaborate why it was a deliberate decision btw? (complex ruby) |
| 15:41 | <workmad3> | it's all just crazy anyway... encoding issues only exist because people were insane, and they turn sane people into insane people even now |
| 15:45 | <annevk> | asmodai, I believe that nobody really requested more than what IE already supported |
| 15:48 | <Philip`> | workmad3: I don't think it's because people were insane - it was logical and sensible to invent all sorts of 8-bit encodings when computers rarely communicated with each other (and especially not internationally), to suit their particular needs |
| 15:48 | <Philip`> | and then it was necessary to continue supporting them for legacy compatibility |
| 15:49 | <Philip`> | which results in all these encoding issues |
| 15:50 | <workmad3> | Philip`: maybe... I'll stick with my 'people are insane' view though, it justifies me cursing encodings more ;) |
| 15:50 | <Philip`> | I'm not saying people aren't insane, just saying that there's other reasons for this situation :-) |
| 15:51 | <asmodai> | annevk: ah ok |
| 15:51 | <Philip`> | and insanity seems a reasonable explanation for why people continue to expose themselves to encoding issues even if they can avoid it (like when inventing new formats and languages), instead of sticking with Unicode internally and UTF-8 externally and not having to worry about it |
| 15:51 | <asmodai> | annevk: I now feel like a proxy XD |
| 15:52 | <annevk> | pretty sure this was already discussed before with Richard |
| 15:57 | <asmodai> | annevk: could be, at least I pointed it out to him now, I'm sure he'll get in contact |
| 16:08 | <asmodai> | annevk: Thanks :) |
| 16:09 | <annevk> | np |
| 17:31 | <MikeSmith> | anybody remember what as the rationale for not making the <rb> element conforming? |
| 17:31 | <MikeSmith> | just for simplification? |
| 17:32 | <MikeSmith> | if there is existing content that uses <rb> and that works as expected in IE, it would seem counter-productive to make such content invalid in HTML5 |
| 17:38 | <Philip`> | MikeSmith: I believe it's not supported in IE |
| 17:39 | <Philip`> | (or it's no more supported than the <thisdoesnotexist> tag) |
| 17:39 | <MikeSmith> | Philip`: OK |
| 17:39 | <MikeSmith> | I guess the issue is that IE does not object to it |
| 17:39 | <Philip`> | It's used sometimes but not always in existing content |
| 17:39 | <MikeSmith> | I see |
| 17:40 | <Philip`> | http://philip.html5.org/demos/html/ruby/wild-examples.html |
| 17:40 | MikeSmith | looks now |
| 17:42 | <Philip`> | I'd guess the reason for excluding is simplification - there's no point requiring people to do something that's unnecessary, and making it optional is adding needless complexity for authors |
| 17:42 | <MikeSmith> | Philip`: I see |
| 17:43 | <Philip`> | though I don't see any explicit rationale in the mailing lists, other than stating it's unnecessary and IE doesn't support it |
| 17:43 | <Philip`> | Also it doesn't seem a very widely used feature so it doesn't hurt too much to make current uses non-conforming |
| 17:44 | <MikeSmith> | that's always a judgement call, I guess |
| 17:44 | <Philip`> | (Apparently I saw it on 0.3% of .jp sites in dmoz.org) |
| 17:45 | <Philip`> | It's nowhere near as numerically significant as making e.g. <br/> conforming |
| 17:45 | <MikeSmith> | I see enough instances of <rb> in that sample at least that I am inclined to think that by prohibiting we are going to risk frustrating and confuseing a significant number sites that are already using it |
| 17:45 | <Philip`> | and people still argued for keeping the syntax simpler in that case |
| 17:47 | <Philip`> | MikeSmith: I expect confusion could be alleviated by validators printing a message saying "the <rb> tag is unnecessary and not permitted in HTML5 - remove the tags and your page will work just fine" rather than just "invalid element <rb>" |
| 17:52 | <MikeSmith> | Philip`: yeah, that we can do |
| 17:53 | <MikeSmith> | and our contract is with users is not that we are guaranteeing that everything that was valid in HTML4 or XHTML1 will continue to be valid in HTML5 |
| 20:23 | <Hixie> | MikeSmithX: .3% iirc is almost as low as the number of pages that use <image>, and we're not making _that_ conforming :-P |
| 21:11 | <knowtheory> | Hixie: if i wanted to write up a proposal for something, is http://dev.w3.org/html5/status/issue-status.html a good place to look at examples of how people have structured other proposals? |
| 21:15 | <othermaciej> | knowtheory: you should look here: <http://dev.w3.org/html5/decision-policy/decision-policy.html>; |
| 21:16 | <Hixie> | knowtheory: no, not really |
| 21:16 | <Hixie> | knowtheory: if you want to propose something, best thing to do is to e-mail whatwg with a description of the problem you want to solve |
| 21:16 | <Hixie> | imho |
| 21:17 | <knowtheory> | okay, thanks guys |
| 22:08 | <JonathanNeal> | Woohoo, today we're putting the new HTML5 stuff into the product. |
| 22:48 | <othermaciej> | knowtheory: the Change Proposal structure is only needed if something has been escalated, not for an initial informal proposal |
| 22:48 | <knowtheory> | othermaciej: okay :) |
| 22:50 | <knowtheory> | i've signed up to the whatwg list, so i'll post there if that's appropriate? |
| 22:57 | <Hixie> | knowtheory: that is one of the appropriate places you can send feedback, yes |
| 22:57 | <Hixie> | (it's one of the places i guarantee a reply eventually, too) |
| 22:57 | <Hixie> | (the other option is the bugzilla system in the html working group) |
| 22:58 | <Hixie> | s/option/place/ |
| 22:58 | <Hixie> | AryehGregor: yt? |
| 22:58 | <Hixie> | or sicking |
| 22:59 | <Hixie> | i'm looking at the empty attribute thread |
| 22:59 | <sicking> | which one? |
| 22:59 | <Hixie> | the one talking about not fetching things for <Script src="">, etc |
| 22:59 | <sicking> | ah |
| 22:59 | <knowtheory> | thanks Hixie |
| 22:59 | <sicking> | Hixie: what about it? |
| 22:59 | <Hixie> | if we make <script src=""> not fetch anything, should we also make it non-conforming? |
| 22:59 | <Hixie> | and does that mean <script src=""> and <script src=" "> would be different from each other? |
| 23:00 | <sicking> | Hixie: i don't feel strongly on conforming vs. non-conforming |
| 23:00 | <Hixie> | (<script src=" "> is non-conforming currently) |
| 23:00 | <sicking> | Hixie: is whitespace generally trimmed from these attributes? |
| 23:00 | <Hixie> | (but it does result in a fetch, which would make it different) |
| 23:00 | <Hixie> | well when resolving the url it is |
| 23:00 | <sicking> | Hixie: i.e. what does " " do currently? |
| 23:00 | <Hixie> | not sure what you mean by "generally" |
| 23:01 | <Hixie> | " " resolves to the base URL |
| 23:01 | <knowtheory> | do CSS Animations actually have a formal relationship to the HTML5 spec? Or is it a detail of browser implementation, that CSS Animations would be included w/ HTML5? |
| 23:01 | <sicking> | Hixie: why does it resolve to the baseurl? |
| 23:01 | <Hixie> | knowtheory: CSS animations are part of CSS, nothing to do with HTML |
| 23:01 | <sicking> | Hixie: wouldn't it convert to "%20" which is appended to the base? |
| 23:01 | <Hixie> | sicking: spaces get trimmed first |
| 23:01 | <knowtheory> | Hixie: cool, just wanted to make sure i wasn't like way off base. |
| 23:02 | <sicking> | Hixie: ah, for relative urls? Or for all values of the attribute? |
| 23:02 | <Hixie> | i'm loathe to make "" invalid everywhere given that it's a valid URL, but making it invalid only in some places is a bit weird... |
| 23:02 | <Hixie> | all values |
| 23:02 | sicking | ponders |
| 23:02 | <Hixie> | the "web addresses" stuff, assuming larry gets around to fixing it properly, trims spaces before resolving urls |
| 23:03 | <Hixie> | seems like making <a href="">foo</a> invalid is a bit weird |
| 23:03 | <sicking> | Hixie: ok, from an implementation point of view, i'd prefer to just tread "" special. I.e. "" != " ". The former does nothing, the latter fetches the base url |
| 23:03 | <Hixie> | but making <script src=""> valid but not do anything is also weird... |
| 23:03 | <Hixie> | oh i agree that "" should be special, not in any way suggesting we make " " be handled differently |
| 23:04 | <Hixie> | it's the conformance aspects of this i'm struggling with |
| 23:04 | <sicking> | Hixie: on the validity issue i don't feel strongly. I agree both options are weird in different ways |
| 23:05 | <sicking> | Hixie: one argument is that it might actually be convenient for authors to be able to use <script src=""> |
| 23:05 | <Hixie> | if we make "" invalid for external-resource <link>s, <link rel="stylesheet index" href=""> would be simultaneously valid and invalid, which is confusing as all hell |
| 23:06 | <Hixie> | but if we make it valid, then <link rel=stylesheet href=""> would be valid but would not have the effect it should have given the url "" |
| 23:06 | <sicking> | Hixie: as to avoid having to do <%if ($bar) {%><script src="<%$bar%>"></script><%}%> |
| 23:07 | <sicking> | Hixie: yeah, i agree with your argument too |
| 23:08 | <sicking> | Hixie: politically it might be easier to make it invalid |
| 23:08 | <Hixie> | i'm not worried about the politics |
| 23:08 | <othermaciej> | really? document validity tends to be more political than implementation conformance |
| 23:08 | <Hixie> | it's the usability of the language i'm worried about |
| 23:09 | <sicking> | then i would say don't make it invalid |
| 23:09 | <sicking> | to avoid forcing authors to use the complex syntax above |
| 23:09 | <Hixie> | having <link rel="stylesheet index" href=""> create just one link but <link rel="stylesheet index" href="#"> create two is very confusing |
| 23:09 | <Hixie> | imhio |
| 23:09 | <Hixie> | imho, even |
| 23:09 | <sicking> | though, i guess you could also argue that <script src=""> is likely a bug, and thus we'd help people by making it invalid so that the validator highlights the bug |
| 23:10 | <Hixie> | that was the argument for making it not fetch anything in the first palce |
| 23:10 | <Hixie> | place |
| 23:10 | <Hixie> | that it was always a bug |
| 23:10 | <sicking> | true |
| 23:10 | <sicking> | ok, make it invalid then :) |
| 23:10 | <Hixie> | is <a href="">foo</a> always a bug? maybe i should just make all empty URLs invalid |
| 23:11 | <sicking> | good question |
| 23:11 | <Hixie> | having some be invalid and some not is very poor form |
| 23:11 | <sicking> | well.. i don't think there are any good solutions here |
| 23:11 | <sicking> | so we'll have to pick one bad solution |
| 23:12 | <Hixie> | if we're picking bad solutions, it seems like making "" actually fetch the local page is the least bad solution from a usability perspective |
| 23:12 | <sicking> | why? |
| 23:12 | <Hixie> | it makes the language self-consistent and predictable |
| 23:13 | <Hixie> | we could say that if you refer to the local page that the UA must use the cached copy always |
| 23:13 | <sicking> | that seems like picking language purity over author friendlyness |
| 23:13 | <Hixie> | "purity"? |
| 23:13 | <Hixie> | it's picking author friendliness over server load friendliness |
| 23:13 | <sicking> | authors are generally in charge of server load. so the distinction doesn't make sense IMHO |
| 23:13 | <Hixie> | if we say that if you refer to the local page that the UA must use the cached copy always, it doesn't even affect the load, which would be good |
| 23:14 | <sicking> | i.e. you'd be hurting the same guy as you're helping |
| 23:14 | <Hixie> | granted |
| 23:14 | <sicking> | and probably hurting him more than helping |
| 23:14 | <Hixie> | but if we use the cache we're not hurting at all |
| 23:14 | <Hixie> | while still being predictable |
| 23:14 | <sicking> | there isn't always a cache around |
| 23:14 | <Hixie> | well, in those cases we can hurt, i guess |
| 23:14 | <Hixie> | there usually is |
| 23:15 | <sicking> | that doesn't seem to be true for <img src=""> |
| 23:15 | <sicking> | given that many browsers gave that special treatment |
| 23:15 | <Hixie> | what isn't true? |
| 23:15 | <sicking> | that there is a cached copy around |
| 23:15 | <Hixie> | i don't see why the browser behaviour indicates that one way or the other |
| 23:16 | <Hixie> | it's just easier to implement "do nothing" than "fetch from the cache and then do nothing because HTML isn't an image format" |
| 23:16 | <sicking> | browsers implemented an exception because there was a detectable difference |
| 23:16 | <Hixie> | by "browsers" you mean FF and Opera |
| 23:17 | <Hixie> | all the other browsers fetch the image, according to the data collected in this thread |
| 23:17 | <sicking> | ah, thought it was more |
| 23:17 | <Hixie> | in fact it's one of the few cases where IE does fetch the URL -- most of hte time it doesn't if it's "" |
| 23:18 | <sicking> | i still don't see how we're helping anyone by saying it should be fetched from cache |
| 23:18 | <sicking> | also, how is "should fetch from cache" different than not saying so? No browsers that i know of fetch from the network for the heck of it |
| 23:19 | <Hixie> | well if fetching from the cache doesn't reduce the load, it's not clear to me why there's a problem here |
| 23:19 | <sicking> | so staying silent on the issue would result in the same browser behavior as far as i can see |
| 23:19 | <sicking> | huh? |
| 23:19 | <sicking> | fetching from the cache would reduce the load |
| 23:19 | <Hixie> | right now, many browsers fetch something in these "" cases. I'm saying we should make it not fetch anything new but just use the available data instead. That seems like it would reduce the load, which is the stated problem. |
| 23:20 | <sicking> | but obviously at least firefox, opera and yahoo felt that the cache didn't reduce the load enough |
| 23:20 | <daedb_> | Why would any author want to use empty src/href? That does not look sane to me :) |
| 23:20 | <Hixie> | i dunno about "obviously" |
| 23:20 | <sicking> | firefox and opera obviously since they implemented it |
| 23:21 | <sicking> | yahoo in general i agree. This guy from yahoo obviously since he spent a lot of time figuring this out while developing the site |
| 23:21 | <Hixie> | i think you're drawing conclusions from the data that aren't warranted -- e.g. opera's behaviour could be a random bug. |
| 23:21 | <Hixie> | anyway, let's start from the beginning |
| 23:22 | <Hixie> | the problem is that authors say src="", data="", etc, but don't mean to |
| 23:22 | <Hixie> | yet they (presumably) say <a href=""> and _do_ mean to |
| 23:22 | <Hixie> | we ideally would want to catch the errors but not flag the intentional cases |
| 23:22 | <Hixie> | we ideally would want to not fetch data from the network for the error cases |
| 23:23 | <Hixie> | we have certain language features where a single href="" can be in both situations at the same time, namely <link rel="stylesheet index" href=""> |
| 23:23 | <sicking> | practically speaking though, when would that markup ever make sense? |
| 23:24 | <sicking> | given that i can't think of a case when it would, I don't care very much what the spec says about it |
| 23:24 | <sicking> | (i only care enough that i don't want to write a bunch of code to handle it, as that is effectively dead code) |
| 23:24 | <Hixie> | <link rel="prefetch next" href=""> might, especially with scripting involved |
| 23:25 | <sicking> | neither "prefetch" or "next" is on the list of suggested changes though, is it? |
| 23:25 | <Hixie> | "prefetch" is |
| 23:25 | <Hixie> | it's an external resource link |
| 23:26 | <sicking> | true |
| 23:26 | <Hixie> | and who knows what future external resource links might be invented |
| 23:26 | <sicking> | ok, so what is your point? |
| 23:27 | <Hixie> | no point, i was just describing the problem |
| 23:27 | <Hixie> | for daedb_'s benefit |
| 23:28 | <sicking> | it seems to me that everyone in that thread agreed on what UA behavior should be |
| 23:28 | <sicking> | so IMHO we should spec that behavior |
| 23:28 | <Hixie> | there's also the mildly interesting case of (XML) <img xml:base="...image..." src="" alt=.../> |
| 23:28 | <ap> | Hixie: <https://bugs.webkit.org/show_bug.cgi?id=30303>;, if you want more opinions on the topic |
| 23:28 | <sicking> | the question of conformance has not been treated though |
| 23:28 | <sicking> | i don't have a strong opinion on that |
| 23:29 | <sicking> | though I think that in general things that are extremely likely to be bugs should be non-conforming |
| 23:29 | <Hixie> | ap: reading... |
| 23:29 | <sicking> | as a rule of thumb |
| 23:30 | <Hixie> | i guess we could make <a href="" rel=next> valid but <link href="" rel=next> invalid |
| 23:31 | <Hixie> | and most authors wouldn't run into it |
| 23:34 | <sicking> | Hixie: sounds ok to me |
| 23:36 | <Hixie> | should <script src=""></script> fire onload or onerror or neither? |
| 23:36 | <Hixie> | and if an event is fired, should it be fired synchronously or asynchronously when parsing? |
| 23:37 | <sicking> | Hixie: i'd say fire onerror. To keep the consistency that onload or onerror is always fired |
| 23:37 | <sicking> | Hixie: and fire asynch, to keep that consistency that all events are async |
| 23:37 | <sicking> | IMHO |
| 23:38 | <Hixie> | events with <script> aren't always async |
| 23:39 | <Hixie> | e.g. <script>document.write('<script onload="alert(1)">alert(0)<\/script>');alert(2);</script> per spec |
| 23:40 | <Hixie> | mind you either firefox nor safari fire that event at all as far as i can tell |
| 23:41 | <Hixie> | actually no browser seems to |
| 23:41 | <Hixie> | huh |
| 23:41 | <othermaciej> | spec bug? |
| 23:42 | <Hixie> | unclear |
| 23:42 | <Hixie> | i think firing onload in that case was an intentional addition |
| 23:42 | <Hixie> | not sure about the sync vs async |
| 23:47 | <Hixie> | ok i made it async in the internal case |
| 23:53 | <Hixie> | should <embed type="application/plugin" src=""> instantiate the plugin based on the type="" attribute, or not at all? |
| 23:56 | <Hixie> | i'll follow <object> and make <embed src=""> do nothing |
| 23:56 | <Hixie> | er, <embed src="" type="..."> that is |