| 00:02 | <Hixie> | what do people think of making <s> valid again, with a semantic something like "indicates that the contents are no longer accurate or no longer relevant" or some such? |
| 00:04 | <Dashiva> | To avoid diluting the semantics of <del>? |
| 00:04 | <Hixie> | yeah |
| 00:04 | <Hixie> | (see http://www.w3.org/Bugs/Public/show_bug.cgi?id=9429 if you have any especially strong opinions one way or the other) |
| 00:06 | <annevk> | not opposed |
| 00:06 | <daedb> | Sounds fine to me, but I don't care strongly about it :p |
| 00:08 | <Dashiva> | I'm not opposed, but it sounds like a semantic fig leaf |
| 00:16 | <othermaciej> | Hixie: <s> is strikethrough? |
| 00:16 | <othermaciej> | what's the difference between <s> and <strike> if any? |
| 00:16 | <othermaciej> | (change sounds good to me btw) |
| 00:17 | <TabAtkins> | othermaciej: No difference. They appear to be the same element? |
| 00:17 | <othermaciej> | I wonder why both exist |
| 00:18 | <othermaciej> | HTML4 had both |
| 00:18 | <TabAtkins> | Presumably because HTML doesn't make any sense. |
| 00:21 | <annevk> | I guess Netscape had <s> and Microsoft had <strike> or vice versa |
| 00:21 | <TabAtkins> | Dashiva: Why do you think so? There is a consistent semantic implied by the use of strike-through in text. |
| 00:22 | <TabAtkins> | It's sort of like <b> taking on the role of "everything that is bold for some important reason, but isn't otherwise covered by another element". |
| 00:22 | <othermaciej> | the <b> definition is also a semantic fig leaf |
| 00:22 | <Dashiva> | Well, what are the major semantic use cases for <s> that aren't covered by <del>? |
| 00:23 | <othermaciej> | <del> implies an edit or edit instruction |
| 00:23 | <othermaciej> | strikethrough in blogs is typically for uses of either "I made a mistake but am being transparent about correcting it" or an ironic fake version of that |
| 00:24 | <othermaciej> | it seems a little different to me than marking up document edits with <ins>/<del> |
| 00:24 | <othermaciej> | like the point of using strikethrough in that context is to *not* delete the stricken text, but rather let it stand and signal that it is no longer operative |
| 00:25 | <TabAtkins> | Actually, I think the first use-case *is* covered well by <del>. They're editting the document. If they were feeling really fancy, they could cite the comment from the pedant that pointed it out. |
| 00:25 | <TabAtkins> | But the ironic fake version probably is abusing <del>. |
| 00:25 | <Dashiva> | So if I'm making ironic emphasis in a quote, I shouldn't use <strong> or <em> either? |
| 00:25 | <othermaciej> | But they are not saying that text has been deleted or should be - rather they are flagging it as false |
| 00:25 | <othermaciej> | or mistaken or unintended |
| 00:26 | <othermaciej> | but explicitly letting it stand for the record |
| 00:27 | <TabAtkins> | Basically, the ironically-stricken text shouldn't be interpreted as ordinary text (that is, it shouldn't be just a <span style>), but it shouldn't be skipped over as a deletion either (and so shouldn't be a <del>). |
| 00:27 | <Dashiva> | (Like Tab says, transparent correction is very much ins/del, otherwise you'd just do the edit directly) |
| 00:28 | <othermaciej> | maybe I do not grok the deep semantics of <del> |
| 00:28 | <othermaciej> | I am not entirely sure what it is supposed to be for |
| 00:28 | <othermaciej> | I imagine if I marked up someone else's document to propose changes, I would use <ins> and <del> |
| 00:28 | <TabAtkins> | Yeah, that's right. |
| 00:28 | <othermaciej> | to me that seems different from transparent correction |
| 00:28 | <othermaciej> | where I am consciously *not* editing the text |
| 00:28 | <othermaciej> | and using strikethrough as an alternative |
| 00:29 | <Dashiva> | What is a correction if not editing the text? |
| 00:29 | <othermaciej> | well, newspaper corrections are generally an external annotation |
| 00:29 | <TabAtkins> | But you are! In most cases I've seen strikethrough used as a transparent correction, the text could be read while completely ignoring the stricken text, and be correct. |
| 00:29 | <othermaciej> | the Web lets you do more of it inline |
| 00:30 | <othermaciej> | TabAtkins: I often see a strikethrough followed by a parenthetical remark explaining the correction, which would not read right if you skipped it entirely |
| 00:30 | <Dashiva> | The only problem with the ironic deletion seems to be that it shouldn't be collapsed |
| 00:30 | <othermaciej> | anyway, I am not the right person for this discussion |
| 00:30 | <othermaciej> | because I don't really care if elements are semantic or presentational, as long as they are useful |
| 00:30 | <Dashiva> | <del permanent-marker> |
| 00:31 | <TabAtkins> | Is that somehow better than <s>? |
| 00:32 | <Dashiva> | Personally I'd be fine with <del> meaning "something removed from the text" without also implying "something that can be removed from the markup" |
| 00:32 | <TabAtkins> | That might be the most pragmatic solution. |
| 00:33 | <TabAtkins> | Hixie, presumably you had a reason why you think that that wouldn't be sufficient? |
| 00:33 | <Dashiva> | If we're adding <s> as ironic <del>, we must also add <u> as ironic <ins> |
| 00:34 | <TabAtkins> | Haha. |
| 00:34 | <othermaciej> | underline seems at best very loosely tied to the semantic if "inserted text" |
| 00:34 | <othermaciej> | not the way strikethrough implies some form of deletion or removal |
| 00:35 | <othermaciej> | also people rarely feel the need to mark up inline correction additions in any way |
| 00:35 | <Dashiva> | Okay, then, <u> as ironic <a> |
| 00:36 | <othermaciej> | I think Hixie's proposed definition of <s> for strikethrough of falsity/irrelevance/inoperativeness captures the distinction between transparent corrections and <del> as text that is/should be deleted |
| 00:36 | <Hixie> | I think "indicates that the contents are no longer accurate or no longer relevant" is quite different than <del>'s edit semantic, personally |
| 00:36 | <othermaciej> | I think <a> works fine for ironic <a> :-) |
| 00:36 | <TabAtkins> | We need use-cases for ironic <a>s, damnit! |
| 00:36 | <Dashiva> | But it's not supposed to be a real link, just look like one |
| 00:36 | <othermaciej> | just put the </sarcasm> close tag at the end of your link |
| 00:36 | <Hixie> | anyway i didn't mean to start a huge conversation, there are far bigger problems :-P |
| 00:36 | <othermaciej> | ironic != fake |
| 00:36 | <TabAtkins> | Hixie, really? What is the edit semantic if *not* "indicating that the contents are no longer accurate"? |
| 00:36 | <Dashiva> | <a></sarcasm> |
| 00:37 | <othermaciej> | TabAtkins: there are lots of reasons to delete content besides "no longer accurate" |
| 00:37 | <othermaciej> | most edits are for style, grammar or conciseness |
| 00:37 | <othermaciej> | and there are reasons to indicate content is "no longer accurate" without deleting it |
| 00:37 | <Dashiva> | I guess my personal interpretation of edit is any change to the document, not just an editioral review |
| 00:38 | <Hixie> | TabAtkins: consider a Fox News script... <del> there could be used for quite the opposite of "no longer accurate" |
| 00:38 | <TabAtkins> | No getting into arguments about absolute truth here. |
| 00:40 | <Dashiva> | Well, it won't be me having to defend it, so go ahead :) |
| 00:41 | <TabAtkins> | JonathanNeal: Your Print Protector showed up in Smashing Magazine's Buzz stream. ^_^ |
| 00:41 | <JonathanNeal> | :) |
| 00:43 | <JonathanNeal> | Remy Sharp is helping me shrink the code down even more. |
| 01:00 | <Hixie> | sweet jesus christ i am so tired of dealing with leif's massive essays |
| 01:00 | <Hixie> | every bug he files or reopens has pages and pages of text |
| 01:00 | <Hixie> | most of which seems to make no sense at all |
| 01:09 | <Hixie> | can someone please translate http://www.w3.org/Bugs/Public/show_bug.cgi?id=9417 for me? |
| 01:11 | <TabAtkins> | I like that the response to "Could you succinctly describe what the problem is?" is 4 paragraphs of text. |
| 01:14 | <TabAtkins> | Nope, sorry, can't parse it either. I'd have to test what he's talking about in order to tell what the problem might be. He hints at things that might be problems, but doesn't actually state precisely *what* the problem is. |
| 01:18 | <Dashiva> | I just want content-language to burn on the pyre of obsoletion |
| 01:23 | <Dashiva> | Hixie: NEEDSINFO, succinct description still missing |
| 01:25 | <Hixie> | Dashiva: he added even more text actually, i ended up just rejecting it based on the new text (which claimed a problem existed which, as far as i can tell, only exists if you go out of your way to make your life hard in the first place) |
| 02:59 | <jlebar> | Hixie, Can I find the old [MIMESNIFF] info somewhere? I'm trying to figure out how to specify sniffing for resource packages (http://limi.net/articles/resource-packages/), but all the HTML5 sniffing language I might look at appears to be out of order. |
| 03:00 | <Hixie> | old MIMESNIFF? |
| 03:00 | <Hixie> | as opposed to the new MIMESNIFF? |
| 03:00 | <jlebar> | "The above is out of date now that the relevant section has been removed from MIMESNIFF. Stay tuned; I'll bring it back here soon." |
| 03:01 | <Hixie> | oh, that stuff |
| 03:01 | <Hixie> | yeah let me just add it back now, hold on |
| 03:01 | <jlebar> | Thanks. :) |
| 03:13 | <Hixie> | jlebar: reload |
| 03:13 | <Hixie> | i'll check it in after lunch when i've reviewed it |
| 03:13 | <Hixie> | afk |
| 03:20 | <jlebar> | Thanks, Hixie. |
| 03:20 | <MikeSmithX> | HTML WG bugmail still does not seem to be getting posted to public-html-bugzilla⊙wo at all |
| 03:20 | <MikeSmithX> | ..and I'm not sure why |
| 03:21 | <MikeSmith> | I think I need to kick something |
| 03:23 | MikeSmith | tries one more thing |
| 06:44 | <JonathanNeal> | hi all |
| 06:47 | <boblet> | hey JonathanNeal |
| 06:47 | <JonathanNeal> | hey boblet |
| 06:55 | <boblet> | can any CSS3 people tell me what’s happening to writing-mode? Seems like it was in the text module but is not now. I’m wondering if that’s temporary or if direction & block-flow are obsoleting it |
| 07:10 | <JonathanNeal> | I suppose you can't link to local files using audio? |
| 07:29 | <boblet> | JonathanNeal: doesn’t file:/// or something relative to source html file work? would expect it to huh |
| 07:30 | <JonathanNeal> | no it doesn't work |
| 07:55 | <hsivonen> | Hixie: I support making <s> conforming |
| 07:56 | zcorpan | expects masses of people outside #whatwg will object to making <s> conforming |
| 07:58 | <hsivonen> | as I see things, <s> means striken but not removable from view and <del> means diff-annotation of an actual delete that could be safely completely deleted |
| 07:59 | <MikeSmith> | hsivonen: what about <strike> ? |
| 08:00 | <hsivonen> | MikeSmith: I'd be OK with having both <strike> and <s> and saying that they are exact synonyms |
| 08:00 | <hsivonen> | in which case it would be logical to make <acronym> conforming, too |
| 08:00 | <MikeSmith> | hmm, yeah |
| 08:00 | <MikeSmith> | so a bit of slipperly slope there maybe |
| 08:01 | <MikeSmith> | though I short slope, I guess |
| 08:01 | <hsivonen> | but if <acronym> were made conforming, it would need very, very obvious spec text saying that <acronym> and <abbr> are normatively synonymous and permathreads are hereby pre-empted |
| 08:02 | MikeSmith | looks back at http://dev.opera.com/articles/view/mama-phrase-block-list/#phrase |
| 08:02 | <MikeSmith> | we still have the unfortunate fact to deal with that <u> is much more commonly used than even <abbr> or <code> |
| 08:03 | <hsivonen> | I'd be OK with making <u> conforming, too |
| 08:03 | <zcorpan> | hsivonen: "Authors must not discuss which of abbr and acronym should be used." |
| 08:03 | <MikeSmith> | if we were going to pick another something to give new semantics to, that should be at the top of the list |
| 08:03 | <MikeSmith> | zcorpan: :) |
| 08:03 | <MikeSmith> | "Authors must STFU." |
| 08:03 | <hsivonen> | even though underlining on the Web generally means links, mapping word processing concepts from the 1990s to the Web benefits from having <u> |
| 08:04 | <hsivonen> | one interesting area of use cases for presentational markup is legal stuff |
| 08:04 | <MikeSmith> | true that |
| 08:04 | <hsivonen> | where there are ancient and typographically crummy conventions |
| 08:04 | <hsivonen> | but the styling is not optional |
| 08:04 | <MikeSmith> | right |
| 08:05 | <MikeSmith> | same with the actual language used in legal documents |
| 08:05 | <hsivonen> | zcorpan: we should have that requirement |
| 08:05 | <hsivonen> | zcorpan: we only need two authors to bite their tongues to make past CR |
| 08:06 | <zcorpan> | hsivonen: they also need to conform to all other criteria that apply to authors |
| 08:06 | <hsivonen> | oh right. I forgot we want two complete interoperable implementations |
| 08:06 | <zcorpan> | we're not svg |
| 08:06 | <hsivonen> | while feature-wise comparison is ok in the CSS WG |
| 08:13 | <myakura> | boblet: I don't know the detail, but it's been split out and moved into a separate module. see http://dev.w3.org/csswg/css3-text-layout/ |
| 08:14 | <boblet> | myakura: doh — I was reading that and didn’t go down far enough. thanks! |
| 08:16 | <myakura> | hm http://lists.w3.org/Archives/Public/www-style/2010Apr/0278.html |
| 08:19 | <boblet> | myakura: do you know if there’s a display property for <rp>, like display:ruby-text? |
| 08:20 | <boblet> | (ie a custom one that isn’t display:none) |
| 08:28 | <boblet> | aah don’t worry. not possible to do that anyway (was trying to fake <rp> via generated content, but can’t then turn it off in browsers that support <rt>) |
| 08:29 | <myakura> | boblet: i dunno. i guess they prolly drop rps from the rendering tree (or something like such) |
| 08:39 | <boblet> | Hixie: re: complex ruby, the advantage of having rbc and rtc elements is the base text and the ruby text don’t need to be intermingled if you want to add ruby per character. Having the ruby all together after the base text is definitely better for non-supporting browsers and for copy&paste. current spec means you loose per-kanji coupling to do that |
| 08:40 | <boblet> | Hixie: PM me if you’d like to see the sample files I’m working on |
| 08:42 | <Hixie> | seems like copy-paste and legacy browsers are just a temporary problem |
| 08:42 | <Hixie> | i'd hate to make the language that much more complicated just for a temporary issue |
| 08:43 | <hsivonen> | I don't like the pattern of UA sniffing Firefox and feeding it some crazy code that it previously accedintally handled but feeding sane code to IE |
| 08:44 | <hsivonen> | I wonder if some guru has taught people that it's OK and even a good idea to document.write a script element to load a "module" in Firefox |
| 08:44 | <Hixie> | the opposite pattern is worse, and more common |
| 08:44 | <jgraham> | hsivonen: everything after and including the word Firefox is superflouous there |
| 08:44 | <hsivonen> | document.write a script from a timeout, that is |
| 08:45 | <hsivonen> | timeout is the key here |
| 08:45 | <jgraham> | UA snifing never seems to end well |
| 08:45 | <jgraham> | </qa_bias> |
| 08:45 | <hsivonen> | oh document.writing from timeout doesn't work in IE, let's do it in Firefox only |
| 08:45 | <hsivonen> | do people think what it means to document.write from a timeout?!11!!1eleventy |
| 08:46 | <jgraham> | What did it mean? |
| 08:46 | <jgraham> | It seems like it could have all sorts of exciting consequences |
| 08:46 | <hsivonen> | jgraham: content gets injected into a timing-sensitive point in the input stream, but only if the parser isn't done yet |
| 08:47 | <zcorpan> | shouldn't it blow away the document? |
| 08:47 | <Hixie> | it inserted it wherever the parser was, more or less (but only at certain points, iirc, e.g. only on token boundaries. i forget the details.) |
| 08:47 | <jgraham> | "please insert this script at a random point in my document, maybe"? |
| 08:47 | <hsivonen> | zcorpan: per spec, yes. in IE, yes. in Gecko with html5.enable=true, yes |
| 08:47 | <zcorpan> | iirc it does in opera also |
| 08:47 | <Hixie> | i remember testing and finding i could insert text into attributes |
| 08:47 | <hsivonen> | zcorpan: in Gecko with the old parser, no if the parser isn't done |
| 08:48 | hsivonen | is dissecting an exciting ad script that exhibits this behavior in Minefield on Windows but not on Mac or Linux |
| 08:49 | <boblet> | Hixie: don’t see how copy-paste issue is temporary |
| 08:50 | <Hixie> | boblet: well presumably it's not how browsers _want_ it to work |
| 08:52 | <boblet> | Hixie: I guess browsers could reorder the text when copying from ruby, but that seems somewhat unlikely. currently even del text shows up in copy-paste |
| 08:52 | <boblet> | adding nested ruby to the mix though… |
| 08:52 | <Hixie> | well copy/paste should do what the user expects |
| 08:53 | <jgraham> | At risk of jumping back to the <s> discussion, with the proviso that <ins> and <del> would be the first elements against the wall if my revolution came, I think that allowing <s> or <strike> or whatver is fine and the fact that there has been discussion about what it means indicates that people won't always use it for what it means |
| 08:53 | <Hixie> | boblet: and i'm pretty sure hte user isn't expecting it to do as you described |
| 08:53 | <boblet> | I definitely didn’t expect del’ed text to show up when c&p’ing a code snippet :O |
| 08:53 | <jgraham> | (or what it would be specced as meaning) |
| 08:54 | <jgraham> | So it should be given a definition that basicaly means "render this as struck through text where possible or in a manner that conveys struck-throughness where not possible" |
| 08:54 | hsivonen | wonders where GeckoActiveXObject comes from |
| 08:55 | <boblet> | i18n and a11y make my head hurt generally. combining them both into one element seems especially cruel :) |
| 08:57 | <boblet> | Does anyone have a clever idea about how to style ruby text in unsupporting browsers? I can change the font-size easily enough, but anything else will also affect supporting UAs… |
| 08:59 | <hsivonen> | haha. the same script assumes that if it find AppleWebKit in the UA string, it'll also find "Version" |
| 08:59 | <hsivonen> | which isn't a safe assumption in e.g. Chrome |
| 08:59 | <hsivonen> | or any non-Safari WebKit-based browser |
| 08:59 | <MikeSmith> | hmm, I just noticed a weird rendering problem in Webkit nightly |
| 09:00 | <hsivonen> | Why does Safari even bother putting the app version in the UA string? |
| 09:00 | <Hixie> | hsivonen: probably for easier stats analysis |
| 09:00 | <MikeSmith> | can somebody look at http://dev.w3.org/html5/markup/figcaption.html and check the "P" in "Phrasing content" and teh "f" in "figure" under "Permitted parent elements"? |
| 09:01 | <Hixie> | hsivonen: makes it more likely people will report "safari" as being used |
| 09:02 | <MikeSmith> | about above -- I mean, first click the link so it becomes a visited link, then check the letters |
| 09:03 | <MikeSmith> | in Webkit nightly they show up in the default (non-visited link) color, whereas the rest of the link is in visited-link color as expected |
| 09:04 | <MikeSmith> | hsivonen: btw, yesterday you mentioned about checking for a nested-figcaption case -- but figcaption can't nest, right? it's only allowed as a child of figure |
| 09:04 | <hsivonen> | MikeSmith: can't !== isn't allowed to |
| 09:05 | <MikeSmith> | ah |
| 09:05 | <hsivonen> | MikeSmith: that is, does the internal state of the checker go crazy, if the end tag of an illegally nested figcaption flips the bit early |
| 09:05 | <MikeSmith> | I see |
| 09:06 | <MikeSmith> | well, for the one test case I tried, it just first gives me an error about the figcaption not being allowed, and the message saying it stopped tehre and did not check the rest of the subtree |
| 09:11 | <boblet> | MikeSmith: re: webkit link coloring, me too on r56990 |
| 09:15 | <MikeSmith> | boblet: thanks |
| 09:16 | <MikeSmith> | seems to be a new bug |
| 09:16 | <micheil> | hmm.. Hixie are websocket servers expected to reply with Set-Cookie headers if Set-Cookie headers were sent? |
| 09:17 | <Hixie> | servers can do whatever they feel is right with cookie headers, basically |
| 09:18 | <micheil> | okay, so, if a server were to drop the Set-Cookie headers, then that wouldn't be against spec |
| 09:18 | <micheil> | right? |
| 09:30 | <boblet> | when copying ruby with per-kanji rt in Chrome, each character and rt text is in source order with a line break between |
| 09:30 | <jgraham> | micheil: That's what I plan on doing initially at least |
| 09:31 | <micheil> | jgraham: do you have your implementation up anywhere? |
| 09:31 | <jgraham> | micheil: It doesn't quite work yet |
| 09:31 | <micheil> | jgraham: so far the only spec compliant server/client I've found is in Go |
| 09:31 | <Hixie> | micheil: right |
| 09:31 | <boblet> | Chrome also doesn’t highlight the second ruby rt correctly — can show highlighted but not copy, and copy when not highlighted |
| 09:31 | <boblet> | fun fun |
| 09:32 | <Hixie> | micheil: personally my web socket toys have not used cookies at all |
| 09:32 | <micheil> | Hixie: any idea who wrote the one for Go? They deserve a pat on the back or something :P |
| 09:32 | <Hixie> | no idea |
| 09:32 | <Hixie> | does it do the latest handshake? |
| 09:33 | <Hixie> | or is it just -75 still |
| 09:33 | <micheil> | yeah, I think so |
| 09:33 | <Hixie> | cool |
| 09:33 | <Hixie> | i wonder if chrome has updated yet |
| 09:33 | <micheil> | http://golang.org/src/pkg/websocket/server.go |
| 09:33 | <micheil> | does the challenge / fingerprint stuff |
| 09:33 | <Hixie> | yeah must be |
| 09:33 | <micheil> | also has a module for draftHixie75 |
| 09:34 | <Hixie> | oh looks like ukai wrote it, cool |
| 09:34 | <micheil> | oh neat :) |
| 09:34 | <micheil> | all I could find on it was "The Go Authors" |
| 09:35 | <zcorpan> | micheil: you should look at the TODO markers ;) |
| 09:36 | <micheil> | oh, good point |
| 09:36 | <Hixie> | looks like he doesn't do the 0xFF trailing handshake yet |
| 09:36 | <Hixie> | but otherwise seems solid |
| 09:37 | <micheil> | trailing 0xFF handshake? |
| 09:37 | micheil | will have to check up on that |
| 09:37 | <zcorpan> | 0xFF0x00 is the closing handshake |
| 09:38 | <micheil> | ah, okay |
| 09:38 | <micheil> | which is the inverse of a empty message packet: 0x000xFF |
| 09:39 | <Hixie> | yes, though that's a coincidence more than anything |
| 09:39 | <micheil> | true |
| 09:43 | <micheil> | looks like the current release of chrome doesn't do the closing handshake |
| 09:45 | <Hixie> | does it do the key stuff? |
| 09:45 | <Hixie> | the closing handshake was added at the same time |
| 09:46 | <beowulf> | Hixie: http://bfbc2.statsverse.com/stats/ps3/carisenda # i have more free time than you :) |
| 09:47 | <micheil> | I'm not sure, I haven't tested yet |
| 09:47 | <Hixie> | beowulf: yet my squad score is higher :-P |
| 09:47 | micheil | is just beginning to write a header parser.. |
| 09:49 | <beowulf> | *mutter* |
| 09:49 | <Hixie> | :-P |
| 09:50 | <hsivonen> | so this time the script didn't call document.write from a timeout |
| 09:51 | <hsivonen> | it called it whenever the HTTP load for another network resource happened to finish |
| 09:52 | <hsivonen> | I still wish ad script authors had a more coherent mental model of how asynchronous processing and document.write interact |
| 09:53 | <annevk> | oh, it's also available for the xbox |
| 09:53 | <Hixie> | and pc |
| 09:54 | <hsivonen> | FWIW, WebKit devs might want to watch out for this same class of evangelism bugs when implementing HTML5-compliant document.write |
| 09:55 | <hsivonen> | this particular script tried to sniff for Safari version in order to be able to do the dangerous thing in new Safari releases that "support" it |
| 09:57 | <hsivonen> | IE and Opera should be fine, because they haven't previously "supported" crazy asynchronous document.wrtie |
| 09:58 | <hsivonen> | I have seen another case, though, that means trouble for WebKit and Presto, because the script assumed that only IE and Firefox support @defer and no one else does |
| 09:58 | <Hixie> | ain't the web grand |
| 09:59 | <hsivonen> | ain't document.write grand |
| 09:59 | <Hixie> | i wish validator.nu warned about empty paragraphs |
| 09:59 | <Hixie> | i keep finding places where i have <dt> instead of </dt> and it would have been caught by that warning |
| 10:00 | <Hixie> | oh actually it wouldn't be caught |
| 10:00 | <Hixie> | maybe i should make that warning also cover phrasing content elements |
| 10:01 | <Hixie> | instead of just flow content ones |
| 10:03 | <zcorpan> | Hixie: maybe you want a warning for omitted optional tags |
| 10:04 | <Hixie> | no, because i use those a lot |
| 10:04 | <Hixie> | and indeed things would have been fine here if i'd omitted them |
| 10:04 | <zcorpan> | true |
| 10:05 | <zcorpan> | maybe you want a warning for included optional tags :P |
| 10:05 | <Hixie> | wouldn't have fired in this case |
| 10:06 | <micheil> | okay.. turns out with a little convincing ryan dahl will be accepting a websocket protocol implementation into the core of node.js |
| 10:06 | <Hixie> | micheil: hopefully not before the protocol is done :-) |
| 10:06 | <micheil> | are many more changes expected? |
| 10:07 | <micheil> | (as in, will the security stuff stay similar?) |
| 10:07 | <Hixie> | who knows |
| 10:07 | <Hixie> | the last set of changes weren't "expected" either |
| 10:07 | <micheil> | oky |
| 10:07 | <Hixie> | ok bed time |
| 10:07 | <Hixie> | nn |
| 10:27 | <MikeSmithX> | so apparently a brief video clip of me being interviewed will be on a Japanese TV program tomorrow night |
| 10:27 | <MikeSmithX> | http://www.nhk.or.jp/itwb/ |
| 10:28 | <MikeSmithX> | they tell me that during the interview, I said "this is the most rapid pace of progress that we have ever had happening around web technologies in the entire history of the development of the web" |
| 10:28 | <MikeSmithX> | and that's the part they're going to use |
| 10:29 | <MikeSmithX> | DJs, feel free to sample that and use it in your mix tapes |
| 10:31 | <Philip`> | More rapid than at the times in the past when people said "hey, let's add images to the web!" and "that sounds like a great idea! let's call it <img>" and two weeks later it was implemented and deployed in all major web browsers? |
| 10:32 | <zcorpan> | Philip`: was it two weeks? i thought it was more like two days |
| 10:33 | <Philip`> | Now it takes us five years just to add something like <figure> which doesn't even do anything |
| 10:33 | <MikeSmithX> | Philip`: yeah, it ain't the most accurate statement in the world |
| 10:33 | <MikeSmithX> | but the *spirit* of the message is what counts |
| 10:34 | <MikeSmithX> | I told them they should have used the part where I looked straight into the camera and said, "We are kicking ass all over the rest y'all and there's nothing you can do about it, so suck it up" |
| 10:34 | <MikeSmithX> | but for some reason they didn't like that part so much |
| 10:35 | <Philip`> | You should have just repeated that phrase for the entirety of the interview, so they'd have no choice but to pick it |
| 10:35 | <zcorpan> | MikeSmithX: did you also say "BTW Adobe eats babies"? |
| 10:35 | <MikeSmithX> | heh |
| 10:36 | <zcorpan> | Philip`: then they'd probably show the entire interview and MikeSmithX would look like a dork on tv |
| 10:37 | <nessy> | Adobe eats my macbook right now |
| 10:38 | <nessy> | if you compare the pace of innovation of html5 to the introduction of <canvas>, then it's light speed |
| 10:40 | <MikeSmith> | zcorpan: I told them, "My message to them is very simple: We drink your milkshake!" |
| 10:41 | <MikeSmith> | to paraphrase Daniel Day Lewis |
| 10:42 | zcorpan | doesn't know what MikeSmith is referring to |
| 10:43 | <Philip`> | MikeSmith: Did you then kill the interviewer? |
| 10:43 | <MikeSmith> | I did |
| 10:43 | <MikeSmith> | and then I ate the pieces of him that were left over |
| 10:44 | zcorpan | now knows not to interview MikeSmith |
| 10:44 | <annevk> | o_O |
| 10:54 | <micheil> | Hixie: latest google chrome beta doens't support the latest spec |
| 10:54 | <micheil> | (based on testing from go's websocket.Handler vs websocket.draft75Handler) |
| 10:55 | <micheil> | now I just need to work out how to use it's client version to test against my own implementations |
| 10:58 | <jgraham> | micheil: If you need really simple testing you can of course just copy the example from the spec and send it over a raw client socket |
| 10:59 | <jgraham> | Won't test all edge cases or anything but should determine if your code works at all |
| 12:36 | <micheil> | jgraham: yeah, I've been doing telnet's to test so far |
| 13:31 | <Matjas> | I recently launched a new site in HTML5, is anyone willing to look at the source and tell me if I'm doing it right? :) http://mathiasbynens.be/ |
| 13:32 | <Matjas> | I just changed section.note into div.note, to improve my document outline — but is there a better alternative? |
| 13:34 | <Matjas> | Also see http://gsnedders.html5.org/outliner/process.py?url=http://mathiasbynens.be/ |
| 13:35 | <annevk> | shortcut is not a valid link relation |
| 13:36 | annevk | is not really inspired right now; should do some more packing for Tokyo |
| 13:36 | <adactio> | Matjas: I think maybe your div.note could be a header element. What do you think? |
| 13:38 | <Matjas_> | annevk: you mean 'shortcut icon'? what should i use instead? |
| 13:40 | <Matjas> | adactio: Hrm, I really don't know. It only appears on the index page |
| 13:40 | <Matjas> | If that even matters |
| 13:41 | <adactio> | Matjas: Well, I think the contents of div.note would make good header content for the section it's in (I'm thinking on the document level rather than a site level). |
| 13:43 | <Matjas> | adactio: I see. And it probably wouldn't be a problem that this header element only occurs on one page, right? |
| 13:43 | <adactio> | Matjas: I don't think so, no |
| 13:45 | <Matjas> | adactio: Thanks. Awesome, now I can even omit the class on the element |
| 13:46 | <Matjas> | annevk: Switched to rel="icon", thanks |
| 13:48 | <Matjas> | annevk: Does that work cross-browser? |
| 13:52 | <svl> | Matjas: no; but the browser in which it doesn't work just looks for favicon.ico in / regardless of what you tell it, so this way it'll work "as intended" everywhere. |
| 13:53 | <Matjas> | svl: Thanks. Which IE versions are we talking about? :) |
| 13:54 | <svl> | I think 6 and 7. not certain about 8 |
| 13:56 | <Matjas> | So why is everyone using shortcut as well? Was is valid in HTML 4.01? |
| 13:57 | <Matjas> | I found this post on the WHATWG blog which contains an example with shortcut: http://blog.whatwg.org/the-road-to-html-5-link-relations#rel-icon |
| 13:58 | Matjas | is confused |
| 13:59 | <svl> | IE needs shortcut if you don't name your icon favicon.ico |
| 14:00 | <Matjas> | So shortcut is not in any spec, but is proprietary? :o |
| 14:00 | <svl> | Yes. IIRC it even needs it as the first value, rather than properly treating it as a space-separated value list. |
| 14:00 | <Matjas> | Mind = blown. |
| 14:03 | <Matjas> | Thanks svl! |
| 14:28 | <zcorpan> | http://www.w3.org/XML/2010/04/xml-stylesheet/ - PER in a few days |
| 16:10 | <JonathanNeal> | Heyo |
| 16:13 | <Matjas> | I'm tired of using technology |
| 16:13 | <Matjas> | Why don't you sit down on top of me |
| 16:13 | <Matjas> | OH SHI— |
| 16:15 | <JonathanNeal> | ... good exit |
| 16:17 | <miketaylr> | indeed |
| 18:59 | <AryehGregor> | Why do Firefox and Chrome both render this with the <th> not centered? data:text/html,<!doctype html><table style="text-align:left"><tr><th>Foo</th></tr><td>Barzabel</td></table> |
| 19:00 | <AryehGregor> | There should be a UA rule like th { text-align: center }, but there's not. Instead, <th> contents seem to be centered by magic. |
| 19:00 | <zcorpan> | hmm, who was it that took my placeholder.js script and improved it a few days ago? |
| 19:01 | <zcorpan> | oh here it is http://fsfe.org/scripts/placeholder.js |
| 19:01 | <AryehGregor> | Well, I guess I mean: data:text/html,<!doctype html><table style="text-align:left"><tr><th>Foo<tr><td>Barzabel</table> |
| 19:01 | <AryehGregor> | Should produce the same DOM, anyway. |
| 19:01 | <AryehGregor> | Opera too. |
| 19:01 | <AryehGregor> | Only IE8 seems to work as expected. |
| 19:02 | <TabAtkins> | HTML5 specifies that <th> should have text-align:center, not magic. |
| 19:02 | <TabAtkins> | So it'll presumably move over in time. |
| 19:03 | <AryehGregor> | So does CSS 2.1. |
| 19:18 | <othermaciej> | WebKit has magic |
| 19:18 | <othermaciej> | it converts text-align: auto to text-align: center at style resolution time |
| 19:19 | <othermaciej> | for th elements |
| 19:19 | <AryehGregor> | https://bugs.webkit.org/show_bug.cgi?id=37590 |
| 19:19 | <AryehGregor> | Is this necessary for compat? |
| 19:19 | <othermaciej> | I am not sure if it's possible to do all the weird legacy compat stuff with an explicit text-align: center rule in place |
| 19:20 | <AryehGregor> | What weird legacy compat stuff needs to be done? Are th's sometimes magically not centered? |
| 19:20 | <AryehGregor> | Does this need to be specced somewhere? |
| 19:21 | <TabAtkins> | I'm curious too. If you're referring to some of the aligning attributes or whatnot, those are on the author level, and thus override UA-level rules. |
| 19:51 | <othermaciej> | AryehGregor: I don't know if our behavior is necessary |
| 19:51 | <othermaciej> | AryehGregor: is the behavior cited in the bug above divergent from other browsers? |
| 19:51 | <othermaciej> | very specifically what we do is that for th, text-align: auto is interpreted as text-align: center at style resolution time |
| 19:51 | <AryehGregor> | othermaciej, I covered that in the bug. Other browsers do the same, except IE8. |
| 19:52 | <othermaciej> | (instead of being equivalent to left as for most elements) |
| 19:52 | <othermaciej> | I suspect the bug could be fixed by making th have an explicit text-align: auto property in the UA stylesheet |
| 19:52 | <othermaciej> | but I don't know if this would break anything else |
| 19:52 | zcorpan | updates http://simon.html5.org/sandbox/js/placeholder-demo.htm |
| 19:53 | <AryehGregor> | Hmm, weird. |
| 20:39 | <smaug> | Hixie: thanks |
| 20:45 | <Hixie> | np |
| 21:09 | <estellevw> | hi. There's a small discussion going on about section versus article in my blog, and i would love to get some feedback (either here or within the comments section) as to what is right. My understanding of the spec is that sections can be nested in articles, and articles can be nested in sections. Am i wrong? http://www.standardista.com/html5-section-v-article/ |
| 21:09 | <Dashiva> | That's right |
| 21:11 | <Dashiva> | It might possibly be easier to think "articles (which have sections) can contain articles" instead of "sections can contain articles" |
| 21:11 | <JonathanNeal> | Hey, everybody! |
| 21:12 | <paul_irish> | so in general, Dashiva, you expect sections will be contained by an article? |
| 21:14 | <JonathanNeal> | Whoa whoa whoa, are we saying that articles and sections are no longer mutually exclusive? |
| 21:15 | <paul_irish> | (i'm not asking for rules, just what we expect common use will be) |
| 21:16 | <Dashiva> | paul_irish: No |
| 21:17 | <Dashiva> | But you can consider the a sufficiently important child of the <body> element a pseudo-article |
| 21:21 | <estellevw> | i do think of it as.... if its datable, it's an article |
| 21:21 | <estellevw> | so, you can have articles.... dated items ... a group of them, in a section |
| 21:21 | <estellevw> | and you can have a bunch of sections in a very long article |
| 21:22 | <estellevw> | i don't see off the top of my head a use case for article within article, but i do section in section |
| 21:22 | <estellevw> | doesn't mean there isn't a use case for articles within articles |
| 21:22 | <estellevw> | i just can't come up with one |
| 21:23 | <Dashiva> | Newspaper letters to the editor |
| 21:23 | <Dashiva> | The page itself is one article, but each letter can also be an article |
| 21:24 | <estellevw> | ah, good one |
| 21:24 | <estellevw> | thank you |
| 21:30 | <JonathanNeal> | Asides can be in articles, right? |
| 21:35 | <Hixie> | sure |
| 21:37 | <JonathanNeal> | Goodie. |
| 21:39 | <othermaciej> | estellevw: the spec definitions of article and section just got reworded recently |
| 21:39 | <othermaciej> | estellevw: don't know if that addresses any of your comment debate but it might be worth looking at |
| 21:39 | <JonathanNeal> | oh neato |
| 21:40 | <othermaciej> | estellevw: I like your explanation of how a section can be either bigger or smaller than an article |
| 21:40 | <othermaciej> | that makes sense to me |
| 21:40 | <estellevw> | thanks |
| 21:40 | <estellevw> | re-reading the spec :( |
| 21:41 | JonathanNeal | looking for the change |
| 21:41 | <othermaciej> | reading the spec is a :( instead of a :)? |
| 21:41 | <othermaciej> | it's mainly in the first sentence of each definition I think |
| 21:41 | <estellevw> | lol. |
| 21:41 | <JonathanNeal> | reading the spec is #) |
| 21:41 | <estellevw> | yeah, the way i was thinking of it still makes sense |
| 21:41 | <othermaciej> | sometimes reading the spec is O_o |
| 21:42 | <estellevw> | i hadn't read the spec since Friday night (because i have a life ;) ) |
| 21:42 | <JonathanNeal> | i hadn't read the spec because I'm a zombie with his tongue sticking out :PF |
| 21:42 | <estellevw> | i was afraid it had changed this then... now just realized, i reread that on monday. |
| 21:43 | <Hixie> | when reading the spec is O_o, please file a bug :-) |
| 21:44 | <estellevw> | Hixie: The spec is so wonderful, that I haven't read any thing else is a few months :D |
| 21:44 | <othermaciej> | Hixie: when I have that reaction, it's usually due to some crazy thing that's needed for legacy compat |
| 21:45 | <estellevw> | is there a way to see ... other than the top of the page, when something has changed |
| 21:45 | <estellevw> | like an SVN diff per line? |
| 21:45 | <othermaciej> | estellevw: there is a twitter feed of spec changes |
| 21:45 | <estellevw> | ah. twitterName please |
| 21:45 | <othermaciej> | http://twitter.com/html5 |
| 21:45 | <estellevw> | thanks |
| 21:45 | <othermaciej> | that links to the diffs for each change |
| 21:45 | <Hixie> | if you just want non-editorial changes, twitter.com/whatwg might be more useful |
| 21:46 | <KaOSoFt> | Hello. |
| 21:46 | <Hixie> | it also includes diffs for other specs than html5 that are part of complete.html, like websockets |
| 21:46 | <Hixie> | also http://html5.org/tools/web-apps-tracker might be helpful |
| 21:47 | <estellevw> | ah, that is perfect. thank you |
| 21:48 | <othermaciej> | I like the examples from your post of a newspaper section vs. a section of an article |
| 21:48 | <othermaciej> | maybe the spec could cite examples like that |
| 21:48 | <Hixie> | happy to add more section and article examples, though there's already quite a few |
| 21:48 | <Hixie> | file a bug |
| 21:49 | <Hixie> | maybe i should have a summary of usage section for the sectioning elements |
| 21:49 | <Hixie> | like we do for phrasing |
| 21:49 | <Hixie> | s/have/add/ |
| 21:49 | <KaOSoFt> | It isn't mandatory to have a form if I want an <input> element, right? I just need a text-box and a submit button for searching. |
| 21:49 | <othermaciej> | that sounds like a good idea |
| 21:49 | <othermaciej> | it looks like you don't have an example of a section containing articles |
| 21:50 | <Hixie> | KaOSoFt: correc |
| 21:50 | <Hixie> | t |
| 21:50 | <othermaciej> | oh, I guess you do, for the blog post with comments |
| 21:50 | <KaOSoFt> | Hixie- Thanks. ^_^ |
| 21:53 | <KaOSoFt> | "<othermaciej> I like the examples from your post of a newspaper section vs. a section of an article" |
| 21:53 | <KaOSoFt> | Where is this? |
| 21:53 | <othermaciej> | KaOSoFt: http://www.standardista.com/html5-section-v-article/ |
| 21:57 | <JonathanNeal> | estellevw's explanation is probably one of the best. |
| 21:59 | <JonathanNeal> | Newspaper letters to the editor, I was wondering if those are sections vs articles, much like a comment section might be a section. However, in the comment section one could say that is definitely datable. |
| 22:01 | <JonathanNeal> | If I knew how to submit stuff to gsnedders's tool, I would suggest the outline allows marking which type of element is in use (it might make people feel better about those untitled navs and asides) |
| 22:01 | <JonathanNeal> | I would suggest == I would write and submit for review |
| 22:03 | <JonathanNeal> | What is the recommended element for comments on a blog post? |
| 22:03 | <estellevw> | the comments is a section, and each comment is dates do article |
| 22:04 | <estellevw> | do = so |
| 22:04 | <JonathanNeal> | And would that section belong to the article that is the blog post? |
| 22:04 | <estellevw> | yes |
| 22:04 | <estellevw> | at least, that's my take on it |
| 22:04 | TabAtkins__ | came in late, but agrees with what estellevw is saying. |
| 22:05 | <JonathanNeal> | <article>... blog post heading and content <section>... blog post comment heading and <article ... various comments /></section></article> |
| 22:05 | <JonathanNeal> | where various comments represents multiple articles. |
| 22:06 | <JonathanNeal> | I agree too, just mulling the concept over. |
| 22:08 | <JonathanNeal> | In a traditional newspaper, each article references the date of the entire paper (usually at the top). Wonder if there would be a geeky semantic way to write in that reference. I would totally make a fake newspaper as HTML5 sample. |
| 22:24 | <TabAtkins__> | JonathanNeal: Nope, you'd have to include the <time pubdate> in every <article>. |
| 22:24 | <JonathanNeal> | No referencing? Not even with microdata? |
| 22:31 | <TabAtkins> | If you have a metadata vocabulary appropriate to the task, then of course you can reference it. But that has nothing to do with the implied connection between an <article> and a <time pubdate> that HTML5 defines. |
| 22:32 | <estellevw> | hhmmm, so a nested article doesn't inherit the pubdate of the parent article. |
| 22:33 | <estellevw> | makes sesne |
| 22:33 | <estellevw> | if instead of thinking of a daily newspaper, think of a monthly mag maybe |
| 22:33 | <TabAtkins> | Or just think of blog posts - the pubdate on the post has nothing to do with the pubdate on the comments. |
| 22:33 | <estellevw> | the magazine may come out on april 1, but the letters to the editor each have their own dates |
| 22:34 | <estellevw> | exactly |
| 22:34 | <JonathanNeal> | All of that would work even if it inherited the date. |
| 22:34 | <JonathanNeal> | If you do not specify the date, it could be implied from an ancestor. |
| 22:36 | <JonathanNeal> | Well, right now you can't, but in theory what issue would you take with that? |
| 22:38 | <TabAtkins> | The fact that it would be inaccurate? |
| 22:38 | <TabAtkins> | Especially in the common case, that of blog comments? |
| 22:44 | <JonathanNeal> | wouldn't the blog comments specify the date? |
| 22:44 | <JonathanNeal> | Otherwise, they're just as omitted in either case. |
| 22:44 | <TabAtkins> | Possibly. If they do, they're covered. But if they don't, your suggestion would imply that they have the same pubdate as the article they're attached to. |
| 22:46 | <JonathanNeal> | You'd rather they had nothing than possibly something. That's fair, you can have them work strict in that sense. |
| 22:48 | <JonathanNeal> | It would be my preference that inheritance is an option. I may be alone. |
| 22:49 | <TabAtkins> | What's wrong with just specifying <time pubdate> in the descendant articles? |
| 22:51 | <JonathanNeal> | It's easier to not do something than to do something. I think it could be less strict. I think there's wiggle room. To compare, we've been talking about comments as articles, then comments aren't exactly independantly distributable content. |
| 22:52 | <JonathanNeal> | \s\ |
| 22:52 | <JonathanNeal> | then\but |
| 22:52 | <TabAtkins> | They're independent chunks of content that can receive their own title and publication date, and are reasonable to link to and look at individually. |
| 22:52 | <TabAtkins> | That's close enough to make <article> a great match, I think. |
| 22:53 | <JonathanNeal> | Do individual comments commonly receive titles? |
| 22:54 | <TabAtkins> | I don't see it universally, but it's reasonable common. Techdirt, for example, has titles on their comments. |
| 23:00 | <estellevw> | It does happen, but it's not the norm (yet). |
| 23:01 | <estellevw> | would most table of contents, though, list each comment individually, or just have the header "comments" in the TOC? |
| 23:01 | <estellevw> | it really depends on the blog i would think |
| 23:01 | <TabAtkins> | Probably the latter. |
| 23:02 | <estellevw> | the "great post" and chatter is not deserving |
| 23:02 | <estellevw> | but some blogs have well thought out responses |
| 23:02 | <estellevw> | even then, one would think the main author would want to determine their TOC |
| 23:02 | <estellevw> | not have their TOC partially filled in my commenters |
| 23:02 | <estellevw> | so, the latter... yup |
| 23:03 | <estellevw> | thinking with my fingers... sorry |
| 23:03 | <TabAtkins> | np |
| 23:16 | <JonathanNeal> | estellevw, thanks for the link to print protector :) just saw |
| 23:23 | <estellevw> | np |