| 00:07 | <TabAtkins> | Man, I always forget that people on the list are actually the bloggers I read regularly. |
| 00:17 | <hober> | how do you delete a page on the wiki? |
| 00:17 | <hober> | specifically, http://wiki.whatwg.org/wiki/Different_Types_of_Ugg_Boots |
| 00:18 | <Dashiva> | Only sysops can delete |
| 00:30 | <Lachy> | hober, I can make you a sysop. What's you're wiki username? |
| 00:31 | <hober> | EdwardOConnor |
| 00:34 | <Lachy> | hober, done |
| 00:34 | <Lachy> | I already deleted that page and blocked the user, though |
| 00:40 | <hober> | thanks, and thanks |
| 01:13 | <JonathanNeal> | Oi, I'm switching our layouts to divs, it's madness. |
| 01:13 | <JonathanNeal> | Esp. when we should have a 960 grid available. |
| 01:55 | <TabAtkins> | Hrm, JonathanNeal? |
| 01:59 | <JonathanNeal> | I'll show you in a bit. |
| 03:12 | <othermaciej> | it's kind of wrong that the HTML5 Cheat Sheet is a PDF |
| 03:14 | <TabAtkins> | That... is kind of wrong. |
| 03:15 | <TabAtkins> | But then again, isn't it designed to be printed? PDF is an output format. |
| 06:37 | <othermaciej> | quiet day here today |
| 07:52 | <othermaciej> | are there any processing requirements for <article pubdate="..."> other than reflecting the markup attribute in the DOM as a string? |
| 07:59 | <hsivonen> | is this for real: http://diveintohtml5.org/ ? |
| 07:59 | <hsivonen> | if so, yay! |
| 08:00 | <othermaciej> | hsivonen: I believe it is real |
| 08:00 | <hsivonen> | I was wondering who'd be the one to write the O'Reilly book |
| 08:00 | <hsivonen> | great to see it's mpilgrim_ |
| 08:01 | <othermaciej> | I kinda love the old timey typesetting features |
| 08:02 | <othermaciej> | hsivonen: have you had a chance to read the PFWG's comments on ARIA vs host semantics? |
| 08:05 | <hsivonen> | othermaciej: not yet |
| 08:07 | <othermaciej> | hsivonen: I thought it looked pretty good - now reading <http://hsivonen.iki.fi/aria-html5-bis/>; to see how well it aligns |
| 08:09 | <hsivonen> | othermaciej: I believe I developed my draft so that it addresses concerns form Michael Cooper's 4th paragraph |
| 08:11 | <hsivonen> | othermaciej: I've now read http://www.w3.org/mid/4A8ADCA2.2000803⊙wo |
| 08:11 | <hsivonen> | othermaciej: looks good to me |
| 08:11 | <othermaciej> | hsivonen: it's not 100% aligned with your old proposal from what I can see, but generally pretty good |
| 08:12 | <othermaciej> | hsivonen: the differences I see are that you suggested disallowing some role values and some states and properties completely |
| 08:12 | <hsivonen> | I can see why someone might argue the native vs. @role precedence to go the other way, but I can "live with it" either way |
| 08:12 | <hsivonen> | othermaciej: for validation |
| 08:13 | <hsivonen> | othermaciej: as far as I can tell, http://www.w3.org/mid/4A8ADCA2.2000803⊙wo allows making those cases non-conforming |
| 08:15 | <othermaciej> | hsivonen: I think the idea there is that ARIA states/properties can only be rendered nonconforming if in conflict with some native semantics |
| 08:15 | <hsivonen> | oh |
| 08:15 | <hsivonen> | I guess I should read the email again |
| 08:15 | <othermaciej> | hsivonen: so for example, it would be in line with what they suggest to say you can't specify aria-level on an <h1> |
| 08:16 | <othermaciej> | hsivonen: but probably not in line to say it's not conforming on a <div> |
| 08:17 | <othermaciej> | hsivonen: aria-hidden seems logical to me since hidden is a global attribute with conflicting semantics |
| 08:18 | <othermaciej> | aria-datatype seems to be gone |
| 08:18 | <hsivonen> | @aria-hidden conflicts globally with @hidden by I imagine the idea is still to allow it everywhere |
| 08:19 | <hsivonen> | yeah, aria-datatype is gone, thankfully |
| 08:19 | <hsivonen> | s/by/but/ |
| 08:20 | <othermaciej> | @aria-owns seems like bad mojo now that I read about it |
| 08:20 | <othermaciej> | hi MikeSmith |
| 08:20 | <othermaciej> | but probably @aria-owns should be removed in ARIA if it is to be removed, and not by HTML5 conformance requirements |
| 08:20 | <hsivonen> | I agree |
| 08:20 | <MikeSmith> | othermaciej: hey |
| 08:22 | <othermaciej> | @aria-templateid also seems to be gone |
| 08:26 | <othermaciej> | hsivonen: I guess aria-html5-bis is a good enough proposal until Hixie is ready to take a cut at it, despite being slightly dated now |
| 08:27 | <hsivonen> | othermaciej: the more up-to-date expression of it only exists in RELAX NG |
| 08:27 | <hsivonen> | I didn't re-express the update in prose/table form |
| 08:28 | <othermaciej> | do you have a link to the RELAX NG version? (not that I can read RELAX NG but maybe others with an interest can) |
| 08:29 | <hsivonen> | othermaciej: http://syntax.whattf.org/relaxng/aria.rnc |
| 08:31 | <othermaciej> | I have confirmed that I don't understand Relax NG |
| 08:36 | <othermaciej> | hsivonen: btw is it intentional that you haven't implemented the current draft alt requirements in validator.nu yet (as far as I can tell anyway)? |
| 08:36 | <othermaciej> | (it doesn't complain about missing alt even if you don't do any of the HTML5 alternative things) |
| 08:36 | <hsivonen> | othermaciej: it's intentional |
| 08:37 | <othermaciej> | the latest alt thread has just made me feel more uncertain what the right thing to do with alt is |
| 08:38 | <hsivonen> | othermaciej: how so? |
| 08:38 | <hsivonen> | (me too, btw) |
| 08:39 | <othermaciej> | hsivonen: on the one hand, your argument that HTML5 as drafted seems at least somewhat against the spirit of ATAG2, and on the other hand, Jonas's point that alt is one of the few pieces of bolt-on accessibility that really works |
| 08:40 | <othermaciej> | hsivonen: for a tool like Dreamweaver, I can accept that if the author fails to add a text alternative, it's their fault the result is nonconforming |
| 08:40 | <othermaciej> | hsivonen: but that doesn't seem reasonable for something like Word's HTML converter, or the ever-popular Flickr example |
| 08:41 | <hsivonen> | for a tool like iWeb, I think it's very clear-cut that there's an error in abstraction layers if user actions cause a syntax error on the HTML level |
| 08:41 | <hsivonen> | however, I think iWeb should still do more to badger users into creating WCAG 2-compliant content |
| 08:41 | <hsivonen> | although there's no way for iWeb to force it |
| 08:41 | <othermaciej> | iWeb does try to hide the underlying HTML from you |
| 08:42 | <othermaciej> | right now it seems to put alt="" on everything |
| 08:42 | <othermaciej> | :-( |
| 08:43 | <hsivonen> | I think it's the user's fault if the tool offered sane UI for creating accessible pages and the user didn't care |
| 08:43 | <hsivonen> | however, I also understand why tool developers feel it's their fault if the output has syntax errors |
| 08:45 | <othermaciej> | actually, there seem to be cases where it omits alt instead |
| 08:45 | <hsivonen> | anyway, I'm willing to try the "missing" marker route from WAI consensus unless someone manages to point out fatal flaws with it |
| 08:45 | <hsivonen> | othermaciej: what cases? |
| 08:45 | <othermaciej> | I don't know, I'm just looking at some iWeb output, not trying to use it |
| 08:46 | <othermaciej> | http://www.hmsbeekeeper.com/HMSB/Blog/Blog.html is made with iWeb |
| 08:46 | <othermaciej> | it seems to put alt="" on presentational images and no alt on actual content images |
| 08:46 | <hsivonen> | I tested iWeb 2.0.4 |
| 08:47 | <othermaciej> | I think the main objection to the idea of a missing marker was that it makes it more work to say the same thing as just omitting alt |
| 08:47 | <hsivonen> | othermaciej: whoa! Apple shipped jsmin.c with sentence that IBM had an issue with! |
| 08:47 | hsivonen | goes check if the iWeb EULA probits use for Evil |
| 08:48 | <hsivonen> | the requirement isn't carried forward to the EULA |
| 08:48 | <othermaciej> | on the other hand, it does seem like a missing marker would make validation more effective at pestering you about alt |
| 08:49 | <othermaciej> | by distinguishing forgotten from omitted because unavailable |
| 08:49 | <hsivonen> | hmm. iWeb seems to incorporate Tidy Lib |
| 08:49 | <othermaciej> | although the current HTML5 draft also sort of distinguishes that, though I'm not sure if the way it does it is better than a "missing" attribute |
| 08:50 | <othermaciej> | hsivonen: various parts of Mac OS X use libtidy |
| 08:50 | <othermaciej> | how can you tell that iWeb uses jsmin.c? distinctive output? |
| 08:50 | <hsivonen> | othermaciej: I clicked "Acknowledgments" in the about box |
| 08:50 | <othermaciej> | hsivonen: I see |
| 08:51 | <othermaciej> | well, I know Apple Legal usually carefully reviews licenses of any third party code we incorporate |
| 09:02 | <hsivonen> | Hixie: does http://oreilly.com/css-html/dive-into-html5/call-it-a-drawing-surface.html use <mark> correctly in your opinion? |
| 09:03 | <annevk5> | Hixie usually uses <strong> or <em> iirc... |
| 09:04 | <annevk5> | it's also not something you'd want to appear on the scrollbar as a tickmark |
| 09:04 | <Lachy> | hsivonen, in the code samples, it looks right to me |
| 09:04 | <hsivonen> | Lachy: even considering what annevk5 said about tickmarks? |
| 09:04 | <othermaciej> | it's also not the kind of thing where you would want native browser UI to jump from one <mark> to the next, afaict |
| 09:05 | <annevk5> | indeed |
| 09:05 | <hsivonen> | I'd also expect command-g to cycle between <mark> elements when there's no user-entered command-f search string |
| 09:05 | <hsivonen> | right |
| 09:05 | <hsivonen> | mpilgrim_: ^ |
| 09:05 | <Lachy> | it's one of the use cases <mark> was designed for, and there's even an example of it in the spec |
| 09:05 | <annevk5> | no it's not |
| 09:06 | <Lachy> | this example from the spec: |
| 09:06 | <Lachy> | <pre><code>var i: Integer; |
| 09:06 | <Lachy> | begin |
| 09:06 | <Lachy> | i := <mark>1.1</mark>; |
| 09:06 | <Lachy> | end.</code></pre> |
| 09:06 | <othermaciej> | hsivonen: interesting idea for what the <mark>-cycling UI should be |
| 09:07 | <othermaciej> | hsivonen: I've been stuck on thinking of one - I don't think the HI team will approve of previous/next buttons for it that are always present in the browser chrome |
| 09:08 | <annevk5> | Lachy, indeed, and the description of the mark element doesn't really give you the impression what the UI in UAs will be either |
| 09:08 | <annevk5> | Lachy, but the suggested UI does not make much sense for examples like that |
| 09:08 | <annevk5> | at all |
| 09:09 | <Lachy> | yeah, but I'm not convinced of the need for a UI like that anyway |
| 09:09 | <othermaciej> | from the UI, it seems like the purpose of <mark> is for something like Google search term highlighting |
| 09:10 | <othermaciej> | or for highlighting lines with your nick in an IRC log |
| 09:10 | <Lachy> | at least, a UI that shows tick marks in the scroll bar all the time would be aweful. Maybe if they were turned on at user request, it might be acceptable. |
| 09:10 | <hsivonen> | I understood the use case to be that user searches on google, user follows link to a site, site grabs google search term from referer and highlights occurrences of the term using <mark> |
| 09:10 | <othermaciej> | I will probably initially implement it without any of the extra UI, just the style rules |
| 09:11 | <Lachy> | othermaciej, yeah, it's for that, as well as highlighting stuff in code samples, quotes, etc. that is relevant to the reader in context |
| 09:11 | <Lachy> | do we need a way to distinguish the two cases? |
| 09:11 | <othermaciej> | Lachy: well for those things, the cycling UI would be pointless, and tick marks in the scroll bars would be terrible |
| 09:11 | <annevk5> | hsivonen, me too |
| 09:12 | <annevk5> | hsivonen, or a cached page with search results highlighted, etc. |
| 09:12 | <othermaciej> | Lachy: I kinda thought the cases you just described were meant to be served by <b> (with possible custom style rules on b) |
| 09:12 | <annevk5> | no, you'd want <strong> as the lines are slightly more important in the context then the surrounding lines |
| 09:13 | <othermaciej> | fair enough |
| 09:15 | <Lachy> | no, mark was introduced so strong wouldn't be abused for that. |
| 09:15 | <gsnedders> | But strong means important |
| 09:15 | <Lachy> | the definition of mark actually does make a distinction between the two cases: |
| 09:16 | <Lachy> | "When used in a quotation or other block of text referred to from the prose, it indicates a highlight that was not originally present but which has been added to bring the reader's attention to a part of the text" |
| 09:16 | <gsnedders> | It's a mess and badly definedm IMO |
| 09:16 | <Lachy> | and "When used in the main prose of a document, it indicates a part of the document that has been highlighted due to its likely relevance to the user's current activity." |
| 09:16 | <othermaciej> | the suggested UI for <mark> seems out of line with the defined semantics and examples |
| 09:17 | <Lachy> | maybe <mark> used within <pre>, <code> and <blockquote> wouldn't be indicated by the UI (like scroll bar tick marks), but other uses outside of those elements would. |
| 09:18 | <annevk5> | Lachy, I think you're wrong and I think "activity" refers to something like searching not reading |
| 09:19 | <othermaciej> | Lachy: that sounds kind of arbitrary |
| 09:19 | <Lachy> | annevk5, I think your wrong, because I remember the discussions from when this was being defined |
| 09:19 | <annevk5> | Lachy, I also do not think it is abuse of <strong> as usage of <em>/<strong> etc. is very context-dependent and that is exactly what is happening here |
| 09:19 | <othermaciej> | annevk5: the spec and examples seem to be in line with what Lachy is saying |
| 09:19 | <othermaciej> | annevk5: although the suggested UI for <mark> is kind of not... |
| 09:19 | <annevk5> | maybe we should fix the spec :) |
| 09:20 | annevk5 | files a bug |
| 09:21 | <annevk5> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=7368 |
| 09:30 | <jgraham> | semantics ftw |
| 09:36 | <nvartolomei> | http://funkyimg.com/u2/203/307/qbfyh2b466kg22q3pym.jpg |
| 09:38 | <othermaciej> | funny, but not really appropriate for this channel |
| 09:55 | <annevk5> | shepazu, btw, changing the interface of <canvas> would break some simple painting application I wrote and have used in a lot of my HTML5 presentations |
| 09:56 | <annevk5> | shepazu, I prototype HTMLCanvasElement; I suspect I'm not the only one |
| 09:56 | <hsivonen> | whoa! did shepazu's draft suggest changing the name of the interface? |
| 09:56 | <hsivonen> | can't have that |
| 09:57 | <othermaciej> | hsivonen, annevk5: I was going to mention that as one of the reasons breaking out the IDL interface doesn't work |
| 09:59 | <Lachy> | hsivonen, yeah, but it does explicitly say that "The interface name itself may be host-language dependent, as may any additional attributes, methods, and objects supported by the element." |
| 09:59 | <hsivonen> | ok |
| 09:59 | <othermaciej> | there's also the fact that reflection between width/height IDL attributes and the relevant canvas markup attributes needs to be defined |
| 09:59 | <Dashiva> | Lachy: Then what is the purpose of separating out the interface? |
| 09:59 | <Lachy> | so I believe shepazu is intending that we would keep HTMLCanvasElement in HTML5, but say that it implements/inherits the CanvasElement interface |
| 09:59 | <Lachy> | Dashiva, I don't know |
| 09:59 | <Lachy> | That's why I told shepazu I didn't think it was a good idea |
| 10:00 | <hsivonen> | Lachy: inheriting might work |
| 10:00 | <othermaciej> | (and you can't define it in the canvas API spec because it doesn't work for <svg:image>, since that already has width and height attributes with a different meaning) |
| 10:00 | <annevk5> | hsivonen, not really |
| 10:00 | <othermaciej> | hsivonen: I think inheriting might not work quite right for the various types of prototype hacking people do |
| 10:00 | <annevk5> | hsivonen, unless you have multiple inheritance |
| 10:00 | <hsivonen> | ok |
| 10:01 | <hsivonen> | I don't know enough about the patterns here |
| 10:01 | <annevk5> | for HTML it needs to inherit from HTMLElement at some point |
| 10:01 | <annevk5> | for SVG probably not |
| 10:02 | <othermaciej> | in fact, I think SVGImageElement already has width and height IDL attributes with different semantics and different types |
| 10:03 | <othermaciej> | (mind you, I'm not sure SVGImageElement is the right SVG element to expose the canvas interface at all, but let's assume it is plausible) |
| 10:03 | <Lachy> | othermaciej, you should point that out in the thread where I said to be cautious about overloading <image> in SVG with the canvas API |
| 10:03 | <annevk5> | I don't quite understand why <foreignObject> is not good enough |
| 10:03 | <othermaciej> | and a third reason is, RenderingContext2D is desirable in some cases where it's not bound to an element at all, as with WebKits canvas background extension |
| 10:04 | <annevk5> | that extension is dubious imo :) |
| 10:04 | <othermaciej> | so it should be spec'd in a way where it can work with a backing store that is not necessarily owned by an element, to make it truly maximally reusable |
| 10:04 | <othermaciej> | annevk5: I don't know if it's great as-is, but there might be things like it that do make sense |
| 10:04 | <Lachy> | othermaciej, how does webkit's canvas background extension work? |
| 10:04 | <othermaciej> | annevk5: like custom-rendered datagrid cells |
| 10:05 | <annevk5> | yeah, that one was interesting |
| 10:05 | <othermaciej> | Lachy: if I recall correctly, it's like a background image in that multiple elements can reference it via style rules, but there's only a single backing store to paint to |
| 10:05 | <annevk5> | it's something like background:-webkit-canvas(ident) |
| 10:06 | <Lachy> | http://webkit.org/blog/176/css-canvas-drawing/ |
| 10:07 | <othermaciej> | anyway, we are not sure of this extension ourselves, this being one reason we have not tried to standardize it |
| 10:07 | <annevk5> | oh look, my memory is pretty decent :) |
| 10:08 | <Lachy> | I don't know what the use cases would be for a dynamic background like that |
| 10:09 | <othermaciej> | Lachy: let's say you wanted to highlight lines of text with a semi-randomized generated appearance that sort of looks like a real highlighter mark |
| 10:10 | <othermaciej> | Lachy: although that would need text metrics... |
| 10:10 | <othermaciej> | but basically any case where you want a purely presentational image, but there's reason to dynamically generate it client side |
| 10:11 | <Lachy> | but even that doesn't require the element interface to be abstracted at all. It just uses the 2D context interface which doesn't strictly need to be attached to an element (except it's not clear what the ctx.canvas property would return) |
| 10:12 | <othermaciej> | Lachy: that's what I'm saying - the 2D context needs to be spec'd purely in terms of a backing store, with ways to define its size and such independent of a specific IDL interface for an element |
| 10:13 | <Lachy> | ok |
| 10:14 | <othermaciej> | and indeed, svg:image already has width and height IDL attributes of type SVGAnimatedLength |
| 10:15 | <othermaciej> | so it would need separate IDL and markup attributes to control backing store size, if it is to be used as a canvas |
| 10:15 | <othermaciej> | anyway, will try to lay all this out in an email soon |
| 10:35 | <Hixie> | hsivonen: yeah, that's acceptable use of <mark> |
| 10:35 | <hsivonen> | Hixie: I'm surprised. |
| 10:35 | <Hixie> | hsivonen: well, i didn't originally think of it as being used in pre |
| 10:36 | <Hixie> | i was only really thinking of blockquote |
| 10:36 | <Hixie> | i should probably do some tweaks |
| 10:36 | <Hixie> | but that's the basic idea of what i had in mind |
| 10:36 | <hsivonen> | Hixie: seems to make <mark> too broad to be useful |
| 10:36 | <othermaciej> | Hixie: the use in dive into html5 and some of the spec examples don't really line up with the suggested browser UI for it |
| 10:37 | <Hixie> | yeah the browser ui may be pie in the sky |
| 10:37 | <Hixie> | maybe the highlight effect is more interesting than the scrollbar highlights |
| 10:37 | <othermaciej> | I mean, I can see cases where scroll bar tick marks and a "jump to next" UI would be really useful |
| 10:37 | <Hixie> | yeah |
| 10:37 | <othermaciej> | it's just that not all the use cases for <mark> as currently defined fit the bill |
| 10:38 | <othermaciej> | (highlighting a referrer's search terms, or the user's nick in an IRC log, seem like valid uses for the proposed UI to me) |
| 10:38 | <hsivonen> | Hixie: if browsers don't become UI-sensitive to <mark>, <mark> will be just another <em> |
| 10:39 | <hsivonen> | in which case we might as well get rid of the whole thing |
| 10:39 | <jgraham> | In general if browsers aren't sensitive to x x becomes another y where y is the element with the closest formatting to x |
| 10:40 | <Hixie> | i think having a highlight element is very different than having a stress emphasis element |
| 10:40 | <Hixie> | but it would be nice to have both a highlight element and a way to highlight content for the scrollbar |
| 10:41 | <Hixie> | maybe i can add an attribute or something |
| 10:41 | <Hixie> | someone file a bug or something about it so i don't forget |
| 10:43 | <othermaciej> | Hixie: Anne filed a bug |
| 10:43 | <Hixie> | thanks |
| 10:43 | <annevk2> | Hixie, <strong> is not emphasis |
| 10:43 | <othermaciej> | (not exactly suggesting an attribute but pointing out that the suggested UI doesn't seem in line with all the examples) |
| 10:44 | <Hixie> | annevk2: strong is importance, which is different than highlighting the relevant part |
| 10:44 | <Hixie> | annevk2: but anyway i'll look at it at some later point |
| 10:44 | <Hixie> | i've been up some 20 hours so far |
| 10:44 | <annevk2> | Hixie, fair enough, but imo the difference is too subtle |
| 10:44 | <Hixie> | one's yellow, the other is bold |
| 10:45 | <Hixie> | it's not that subtle |
| 10:45 | <annevk2> | I usually have some rule code > strong { color:purple } |
| 10:46 | <othermaciej> | the visual difference of highlighting vs bolding I think will convey a different sense to people who are used to print |
| 10:46 | <othermaciej> | but the semantic difference seems subtle |
| 10:49 | <Hixie> | anyway i should sleep |
| 10:49 | <Hixie> | nn |
| 10:49 | <othermaciej> | good night |
| 11:06 | <Lachy> | The semantic difference isn't that subtle. One is denoting relevance, the other importance. |
| 11:07 | <annevk2> | and the more relevant line is more important to the user |
| 11:07 | <annevk2> | bwah |
| 11:24 | <hsivonen> | that strong is about importance borders on angels on the head of a pin |
| 11:26 | <Dashiva> | Are there some canonical examples of important non-relevant, relevant non-important and important-and-relevant? |
| 12:07 | <zcorpan> | A: Yes. The default font is 10px sans-serif. Sizes in em or percentages are measured against the default font." -- http://diveintohtml5.org/canvas.html |
| 12:08 | <virtuelv> | isn't exposing the BarProp properties a security issue? |
| 12:08 | <zcorpan> | Hixie: see? now change the spec :) |
| 12:16 | jgraham | wonders what zcorpan wants changed |
| 12:16 | <Lachy> | zcorpan, what was the question? I don't see it in the backlog |
| 12:16 | <jgraham> | hint: I don't remember much about canvas text |
| 12:17 | gsnedders | points at public-html |
| 12:17 | <gsnedders> | Honestly, don't you read it? |
| 12:18 | <jgraham> | gsnedders: Actually it turns out that that was one of the 2505 messages I haven't read on public0html |
| 12:19 | <Lachy> | gsnedders, which mail specifically? |
| 12:20 | <Lachy> | this one from about 18 days ago seems to be the only relevant one http://lists.w3.org/Archives/Public/public-html/2009Aug/0007.html |
| 12:24 | <gsnedders> | Ow. I just hiccuped and bit my tongue. The poor little boy is in pain. |
| 12:40 | <zcorpan> | jgraham: the spec says em and % in canvas text is relative to the canvas element's computed style (if it has one, or 10px sans-serif otherwise) instead of being relative to the default (10px sans-serif) |
| 12:41 | <zcorpan> | jgraham: i want it to always be relative to the default (10px sans-serif) |
| 12:42 | <jgraham> | zcorpan: Yeah I read your mail. I agree that sizes should always be relative to the same thing |
| 12:42 | <zcorpan> | jgraham: i would appreciate if you said so on the list :) |
| 14:56 | <annevk2> | http://twitter.com/inboxzero heh |
| 14:56 | <annevk2> | (via daringfireball) |
| 15:12 | <annevk2> | hsivonen, did you also get "MTV News is now following you on Twitter!"? |
| 15:14 | <hsivonen> | annevk2: I've turned those off |
| 15:14 | <hsivonen> | annevk2: let's see if they are following me |
| 15:17 | <hsivonen> | annevk2: it seems they aren't following me |
| 15:17 | <TabAtkins> | Lucky you, Anne. |
| 15:19 | <othermaciej> | sigh, still can't sleep |
| 15:21 | <Dashiva> | The biggest problem with a dungeon is the ventilation. |
| 15:22 | <annevk2> | TabAtkins, I still haven't quite figured out what the big benefit of a big follower count is |
| 15:22 | <TabAtkins> | Big follower count = big penis. |
| 15:22 | <TabAtkins> | Dashiva: You talking D&D-style dungeons? |
| 15:23 | <Dashiva> | No, http://twitter.com/diveintomark/status/3399044637 |
| 15:23 | <annevk2> | TabAtkins, so Oprah has 2M followers... |
| 15:23 | <TabAtkins> | annevk2: Oprah's penis is roughly 3 meters long. |
| 15:24 | <TabAtkins> | Dashiva: Ah, kk |
| 15:24 | <othermaciej> | that is a disturbing image |
| 15:25 | <TabAtkins> | Yeah, take *that* to sleep with you. |
| 15:25 | <Dashiva> | My bed is only 2 meters, it wouldn't fit |
| 15:27 | TabAtkins | needs to go get his daily Sonic fix. |
| 15:29 | <miketaylr> | man, i wish we had sonic in new york |
| 15:33 | <annevk2> | hmm, a lot of the encoding tests just fail in Firefox 3.7a on Windows 7... |
| 15:36 | <hsivonen> | annevk2: with html5.enable = true? |
| 15:37 | <annevk2> | i hadn't changed prefs yet |
| 15:37 | <annevk2> | i'll enable that |
| 15:38 | <annevk2> | reboot? |
| 15:38 | <annevk2> | s/reboot/restart/ ? |
| 15:39 | <hsivonen> | annevk2: no need to restart the browser after setting it |
| 15:40 | <annevk2> | seems to run better with it enabled... |
| 15:41 | <hsivonen> | cool |
| 15:54 | <TabAtkins> | html5.enable isn't in the shipping 3.5, right? |
| 15:54 | <gsnedders> | TabAtkins: right |
| 15:55 | <TabAtkins> | miketaylr: Yeah, you're missing out. I'm pretty sure I'm physically addicted to 44oz double-vanilla Dr. Peppers. |
| 15:55 | <inimino> | TabAtkins: right |
| 15:57 | <miketaylr> | TabAtkins: every now and then i get a fix when i go back to my parents home in oklahoma... ;) |
| 16:06 | <gsnedders> | hsivonen: There's a bug in html5 enabled Fx giving the wrong tree through DOM unless there's an alert first |
| 16:07 | <hsivonen> | gsnedders: test case? |
| 16:07 | gsnedders | was expecting that |
| 16:08 | <hsivonen> | gsnedders: with which parser? |
| 16:08 | <gsnedders> | hsivonen: HTML 5 |
| 16:08 | <hsivonen> | gsnedders: known issue in the old one |
| 16:08 | <hsivonen> | that's bad |
| 16:08 | <gsnedders> | This particular bug doesn't exist in the old one as far as I can tell |
| 16:08 | <hsivonen> | gsnedders: does it involve object, applet, video or the like? |
| 16:08 | <gsnedders> | No |
| 16:09 | <hsivonen> | interesting |
| 16:09 | <gsnedders> | Just the last node in the document being a text node |
| 16:09 | <hsivonen> | gsnedders: oh do you mean you can't see document.written trailing text via DOM? |
| 16:10 | <gsnedders> | hsivonen: yeah |
| 16:10 | <gsnedders> | Yeah, it is only document.written text |
| 16:10 | gsnedders | only just found that out |
| 16:10 | <hsivonen> | gsnedders: an alert shouldn't help with that |
| 16:10 | <hsivonen> | but yeah, known issue |
| 16:10 | <gsnedders> | hsivonen: Got a bug for that? |
| 16:10 | <hsivonen> | basically, I aligned with WebKit |
| 16:10 | <hsivonen> | than Hixie said aligment with IE was right |
| 16:11 | <hsivonen> | gsnedders: I think there's no bug. I'll file one |
| 16:11 | <hsivonen> | gsnedders: Opera has the same bug/design, IIRC |
| 16:12 | <gsnedders> | We match HTML 5 as far as I can tell |
| 16:12 | <gsnedders> | http://html5.org/parsing-tests/testrunner.htm fails a lot in Fx because of it |
| 16:13 | <gsnedders> | hsivonen: Why does it depend upon the presence of an alert though? |
| 16:13 | <hsivonen> | https://bugzilla.mozilla.org/show_bug.cgi?id=511405 filed |
| 16:13 | <hsivonen> | gsnedders: it shouldn't! |
| 16:13 | <hsivonen> | gsnedders: that's very odd |
| 16:14 | <gsnedders> | hsivonen: Using an alert seems to flush the buffer |
| 16:14 | <gsnedders> | hsivonen: Also, shouldn't document.close() flush it? |
| 16:15 | <hsivonen> | gsnedders: yes. |
| 16:15 | <gsnedders> | Hmm, my minimal TC is too minimal :) |
| 16:15 | <hsivonen> | gsnedders: ooh. you use document.close! |
| 16:15 | <hsivonen> | it doesn't flush synchronously |
| 16:15 | <gsnedders> | s/you/zcorpan/ :) |
| 16:15 | <hsivonen> | alert spins the event loop, so it gets flushed |
| 16:16 | <hsivonen> | alert doesn't affect document.write AFAIK but does affect document.close |
| 16:16 | <gsnedders> | You got any got idea of how to fix that script? |
| 16:16 | <gsnedders> | (or should it just be fixed in fx?) |
| 16:17 | <hsivonen> | document.write a comment after the text |
| 16:17 | <hsivonen> | it'll take a while before I get to fixing it |
| 16:17 | <gsnedders> | Then magic is needed to avoid that causing all tests to fail |
| 16:18 | <jgraham> | gsnedders: Can't you use a data url rather than document.write, or something? |
| 16:18 | <hsivonen> | gsnedders: can you use setTimeout for the continuation ofter document.close? |
| 16:18 | <hsivonen> | *after |
| 16:18 | <hsivonen> | gsnedders: it fails in WebKit, too, right? |
| 16:19 | <gsnedders> | hsivonen: Weird stuff happens in WebKit with that script :) |
| 16:19 | <gsnedders> | Like throwing when writing <script><div><script> into the iframe in the specific case, but not when doing it outside of that script |
| 16:49 | <TabAtkins> | Woo! Bert just invited me to be part of the CSS WG! |
| 16:51 | <othermaciej> | grats! |
| 16:51 | <othermaciej> | (I guess?) |
| 16:52 | <TabAtkins> | Heh, this is a good thing. |
| 16:53 | <TabAtkins> | I've been interested in this sort of thing for a long time. ^_^ |
| 16:56 | <sgalineau> | Cool, I was going to remind him to send that mail :) |
| 16:57 | <TabAtkins> | ^_^ Thanks, Sylvain. |
| 17:01 | <othermaciej> | TabAtkins: how did you first get into standards stuff? |
| 17:01 | <TabAtkins> | Hixie's and Hakon's blogs, when I first started picking up web projects here at work. |
| 17:01 | <TabAtkins> | Sorry, Tantek, not Hakon. |
| 17:01 | <othermaciej> | good places to start I guess :-) |
| 17:02 | <sgalineau> | I didn't even know Hakon and Tantek had blogs (feeling clueless) |
| 17:02 | <TabAtkins> | I only *started* doing webdesign like two years ago, and when I was first teaching myself through googling, they were referenced a lot. |
| 17:02 | <TabAtkins> | Hakon might not, I dunno. |
| 17:03 | <TabAtkins> | Posts like the "levels of HTML knowledge" and "bed and <br>eakfast markup" were real eye-openers for my virgin self. |
| 17:03 | <sgalineau> | whoa. talk of tab virginity early in the morning. |
| 17:04 | <TabAtkins> | web virginity only. |
| 17:04 | <TabAtkins> | And, um, I guess only a very specific *kind* of web virginity. |
| 17:04 | <TabAtkins> | Webdevirginity? |
| 17:04 | <sgalineau> | found the levels of HTML knowledge, can't place the other one |
| 17:05 | <TabAtkins> | http://tantek.com/log/2002/10.html#L20021022t1432 |
| 17:06 | <TabAtkins> | And Hixie's deconstructions of popular sites, ripping them apart for their nonsemantic structure, were very helpful in shaping me. |
| 17:06 | <TabAtkins> | Then I just joined the css and whatwg lists, and started participating from there. |
| 17:06 | <sgalineau> | I definitely need to design more. only way to be good at this. |
| 17:07 | <TabAtkins> | Yup. |
| 17:07 | <sgalineau> | ...could make me hate my employer though....:) |
| 17:08 | <TabAtkins> | That or tip you over into the "Everything MS does is *GOLD*, I tell you!" camp. |
| 17:08 | <sgalineau> | that is quite the unlikely scenario |
| 17:08 | <TabAtkins> | ^_^ |
| 17:09 | <sgalineau> | I've used Opera Show for CSS presentations and wore a Firefox 1.0 t-shirt on my first day. and that was the least offensive stuff. |
| 17:10 | <TabAtkins> | If more computers at my college had Opera installed, I would have used that a lot. Instead I just designed a basic slideshow thinger in PHP. |
| 17:10 | <TabAtkins> | Tell me: how did the IE team react to that shirt? |
| 17:11 | <sgalineau> | told me to upgrade :) |
| 17:11 | <TabAtkins> | Hahaha |
| 17:11 | <sgalineau> | as in, Firefox 1.0 is too old |
| 17:12 | <sgalineau> | at the last WG meeting, I had a microsoft t-shirt that says 'I am the empire' |
| 17:12 | <sgalineau> | Hakon had to take a picture of that |
| 17:13 | <TabAtkins> | I approve. |
| 17:13 | <TabAtkins> | Now I just need to get my company to start funding my travels around the globe for the FtFs. |
| 17:14 | <TabAtkins> | Alternately: convince my wife that we're going on vacation a lot. |
| 17:15 | <sgalineau> | next two are in the US |
| 17:15 | <sgalineau> | west coast |
| 17:15 | <sgalineau> | bay area |
| 17:16 | <TabAtkins> | Is bar area near SF, or LA? |
| 17:16 | <sgalineau> | sf |
| 17:16 | <TabAtkins> | Damsn. I've got family near LA. |
| 17:16 | <sgalineau> | next meeting is at the W3C TPAC in Santa Clara |
| 17:16 | <sgalineau> | following one at Apple I think |
| 17:16 | <sgalineau> | then in August in Oslo at Opera. I'd save us for that and make it a vacation |
| 17:17 | <TabAtkins> | Ooh, going to Norway would we awesome. August next year? |
| 17:18 | <sgalineau> | yup |
| 17:18 | <sgalineau> | Oslo in August is supposed to be really lovely |
| 17:19 | <sgalineau> | I should be paying attention to the CSS WG telcon. I'm not smart enough to be an invited expert.... |
| 17:19 | <TabAtkins> | Hmm. 5th anniversary would be next June. Maybe keep that small and take an august trip... |
| 17:20 | <sgalineau> | we'll drink red stripe in champagne flutes. |
| 17:20 | <TabAtkins> | It's a date. |
| 17:20 | <TabAtkins> | A, um, three-way date. With my wife. |
| 17:20 | <sgalineau> | you realize that you're suggesting a three-way date to a frenchman...right ? |
| 17:21 | <TabAtkins> | Indeed. |
| 17:21 | <TabAtkins> | I don't know how to make that dirty french laugh thing in words. |
| 17:21 | <TabAtkins> | But I'd do it if I could. |
| 17:23 | <TabAtkins> | Also: apparently your picture on Facebook reminds my wife of an old boyfriend. |
| 17:23 | <sgalineau> | lol |
| 17:25 | <TabAtkins> | Wow, tantek's use on his blog of <p> as an inline element with a marker at the beginning to separate it from surrounding <p>s is... weird. |
| 17:32 | mpilgrim | is not looking forward to the "here's all the new semantic markup you can use in html 5" chapter of diveintohtml5 |
| 17:32 | <mpilgrim> | given the level of discussion over the <mark> element |
| 17:33 | <othermaciej> | most of the other new semantic markup is pretty clear-cut in its usage |
| 17:33 | <mpilgrim> | maybe i should just call the chapter "what color is your bikeshed?" and be done with it |
| 17:33 | <mpilgrim> | hahaha |
| 17:33 | <mpilgrim> | it's cute that you think that |
| 17:33 | <othermaciej> | easy for me to say, I don't have to write web pages for a living |
| 17:34 | <jgraham> | We need an interoperability test for semantic markup. Unless we can prove that a majority of authours are using markup in accordance with the specified semantic the spec shouldn't be allowed to go to Rec. |
| 17:34 | <TabAtkins> | I think <article> is still a bit confusing. The example usage seems to conflict with what I want to use it for, which is something to wrap the main content of a page. |
| 17:34 | <othermaciej> | TabAtkins: it's not really suitable for that in the general case, although a <main> or <content> element for that has been proposed |
| 17:35 | <TabAtkins> | Yeah, saw that discussion a few days ago. |
| 17:35 | <jgraham> | I am quite concerned at the difficulty people have with the sectioning elements in general. I mean people couldn't use headings in HTML 4 either but I sort of hoped we could do better |
| 17:35 | <othermaciej> | the only one I find somewhat confusing is <section> itself |
| 17:36 | <TabAtkins> | I think a focus on "this shit generates entries in outlines" might help? |
| 17:36 | mpilgrim | sits back and waits for everyone to prove his point |
| 17:36 | <TabAtkins> | But then you'd have people saying "wtf use are outlines?" |
| 17:36 | <TabAtkins> | mpilgrim: hahaha |
| 17:37 | <othermaciej> | well, the section elements are supposed to be for web applications to, and an outline of an app is at the very least hard to think about, if not outright incoherent |
| 17:37 | <TabAtkins> | I guess. |
| 17:37 | <jgraham> | TabAtkins: Indeed. But it depends if you can get good results (x-epsilon)% of authors who don't get the outline thing |
| 17:38 | <TabAtkins> | I think the "it resets your <h1-6> nesting" is the primary take-away use I get from <section>. |
| 17:38 | <jgraham> | othermaciej: I think of them as being basically document constructs by analogy with LaTeX. But it makes some sense for applications too |
| 17:38 | <othermaciej> | also most people will never actually be exposed to the outline, so we can expect the same quality as for other invisible metadata |
| 17:38 | mpilgrim | waits for the accessibility experts to magically become semantics experts and highlight this entire conversation in the irc logs |
| 17:38 | <jgraham> | If there is a use case for jumping between parts of the application UI |
| 17:38 | <othermaciej> | I love reading commentary on IRC conversations in email |
| 17:39 | jgraham | hopes that hsivonen will put the outline on validator.nu so it gets the same exposure as other authoring errors |
| 17:39 | <TabAtkins> | That would be nice. |
| 17:40 | <TabAtkins> | I've got an outlining tool in Web Developer FF add-on, but it doesn't understand the html5 algorithm so it just assumes everything is a top-level entry. >_< |
| 17:40 | <TabAtkins> | Plus: it's pretty well-hidden. |
| 17:41 | <othermaciej> | I mean, Google Calendar clearly has separate "sections" in the layout but I'm not sure an outline of them is a sensible idea |
| 17:41 | <mpilgrim> | TabAtkins: i like the framing of "it resets your <h*> nesting" |
| 17:41 | <othermaciej> | I guess it's easier to understand elements that actually do stuff |
| 17:42 | <mpilgrim> | i think i'll name the chapter "two headers are better than one" |
| 17:42 | <othermaciej> | no one wonders when to use <canvas> or <video> |
| 17:42 | <TabAtkins> | I ran into really annoying issues with <h*> nesting (I like <h*> best of all!) when designing the template for my site. |
| 17:43 | <jgraham> | othermaciej: As far as I can tell that is basically the "semantics failed" position |
| 17:43 | <sgalineau> | Tab, where's your site ? |
| 17:43 | <TabAtkins> | I ended up having to start the content at like <h4>, which was confusing as hell because you never see the <h1> - <h3> elements because they're in the template. |
| 17:43 | <TabAtkins> | I do all of the sites for my company, http://www.igofigure.com |
| 17:43 | <TabAtkins> | Plus several intranet apps for same, all hidden behind password walls. |
| 17:44 | <TabAtkins> | My personal site is just a dumping ground of random stuff, plus my silent evangelism for Internet Time, www.xanthir.com |
| 17:44 | <sgalineau> | love the comments : "Yes, this is a table-based layout. Yes, I am ashamed of myself." |
| 17:44 | <TabAtkins> | Hahaha, yeah. |
| 17:46 | <Lachy> | I really don't get what's so hard about the sectioning elements, especially considering how many people kept asking us to add XHTML2-style sectioning/headings despite already having it |
| 17:48 | <sgalineau> | they may have been vocal, but clearly they were not representative |
| 17:48 | <othermaciej> | it's not really clear to me when to use <section> and when to use <div> in something that's not a traditional document structure |
| 17:49 | <Lachy> | mpilgrim, I think the easiest way to illustrate the sectioning element's function is to use a diagram showing how a document is structured. |
| 17:49 | <jgraham> | othermaciej: If it has a header it is likely a <section> if not probably a <div> probably works in many cases |
| 17:49 | <jgraham> | s/header/heading/ |
| 17:49 | <Lachy> | first get people thinking about documents in terms of their outline structure, and then it's much easier to get them to use the markup correctly |
| 17:49 | <mpilgrim> | as you may have noticed, i'm trying to explain things more visually in diveintohtml5 than in my previous books |
| 17:49 | <TabAtkins> | jgraham: Yeah, that's my take. Combined with the "resets <h*>" focus, it's relatively clear. |
| 17:50 | <mpilgrim> | so yeah, a diagram is probably a good solution |
| 17:50 | <TabAtkins> | Use it when you have headings, *because* it resets your headings. |
| 17:50 | <othermaciej> | mpilgrim: I haven't read your previous books (for shame) but I love the old timey typesetting elements in this one |
| 17:51 | <mpilgrim> | thanks |
| 17:51 | <mpilgrim> | my O'Reilly editor likes it too |
| 17:51 | <TabAtkins> | Honestly, since the first chapter I saw was for <canvas>, I thought the giant ornate dropcap was a <canvas>. |
| 17:51 | <mpilgrim> | not sure how much of it will translate into print form |
| 17:52 | <mpilgrim> | they're pretty strict about their brand, and typography is a big part of their brand for obvious reasons |
| 17:52 | <jgraham> | Yeah the typography is nice. It feels (perhaps wrongly) somewhat _why influenced |
| 17:53 | <mpilgrim> | that was one of my influences, yes |
| 17:53 | <TabAtkins> | _why is the ruby dude, right? |
| 17:53 | <mpilgrim> | along with o'reilly's head-first series |
| 17:53 | <mpilgrim> | (this is not a head-first book, but i like some of the design elements) |
| 17:55 | <mpilgrim> | the typography was created using Philip`'s font subsetting scripts |
| 17:55 | <mpilgrim> | including the IE-compatible .eot files |
| 17:55 | <TabAtkins> | Dang, Philip` does everything. |
| 17:55 | sylvaing2 | reflexively dodges at the mention of EOT |
| 17:56 | <Philip`> | I hope you didn't use my scripts on OFL-licensed fonts, because that would violate their licence |
| 17:56 | <mpilgrim> | that's upsetting news |
| 17:56 | <TabAtkins> | License proliferation for the lose. ;_; |
| 17:56 | <mpilgrim> | linux libertine is OFL-licensed IIRC |
| 17:56 | <Philip`> | ...because of the Reserved Name stuff which I haven't got around to fixing yet |
| 17:57 | <mpilgrim> | is there a url explaining this problem? |
| 17:57 | <Philip`> | (You're not allowed to use the original font's name in a modified version, but my scripts keep the old name and prefix it with "subset of") |
| 17:57 | <mpilgrim> | i see |
| 17:57 | <Philip`> | See the OFL licence, I think it's fairly clear about it |
| 17:57 | <jgraham> | mpilgrim: Libertine seems to be GPL/OFL dual licensed |
| 17:58 | <Philip`> | You could always use my font-name altering script to alter the font's name so it's no longer in violation :-) |
| 17:58 | <mpilgrim> | jgraham: hooray for dual-licensing! |
| 17:58 | <mpilgrim> | (man, how many times do you get to say that?) |
| 17:58 | <Philip`> | or wait until next week or something when I'll probably fix my code |
| 17:58 | <Dashiva> | mpilgrim: Every time you're a user and not a developer? :) |
| 17:58 | <mpilgrim> | i've been a developer since i was 11 |
| 17:59 | <Dashiva> | Well, whenever you're not wearing your dev hat |
| 17:59 | <Philip`> | Your ten-year-old self would surely have appreciated dual-licensing |
| 17:59 | <mpilgrim> | jgraham: you are correct, it's dual-licensed under OFL and GPL-with-font-exception |
| 17:59 | <mpilgrim> | i shall update my about page to mention which license i'm using |
| 17:59 | <mpilgrim> | and call it a day |
| 18:00 | <Philip`> | If you distribute a GPL font, do you have to distribute the original FontForge (or whatever) editable source version? |
| 18:00 | <Dashiva> | Surely you only have to have it available on request? |
| 18:01 | <mpilgrim> | i don't know, but i would be happy to do so |
| 18:01 | <Philip`> | Dashiva: Well, that too |
| 18:02 | <Dashiva> | (as in, you don't actually bother until someone sends an email and asks) |
| 18:04 | <mpilgrim> | i aim to be maximally license-compliant, so i will add the font sources to my repository and link them from the about page |
| 18:04 | <Philip`> | I hope you don't care too much if your fonts aren't spec-compliant |
| 18:16 | <TabAtkins> | Is there any reason to ever have a document with multiple <articles> that *aren't* wrapped by an overall <article>? |
| 18:17 | <TabAtkins> | I'm thinking that maybe blogs using <article> for comments (as suggested by the spec) might not want to wrap a big <article> around the whole thing. |
| 18:18 | <miketaylr> | by 'the whole thing', you mean the entire document, or just the article people are commenting on? |
| 18:19 | <TabAtkins> | The whole actual content area of the document (that is, not the site header or sidebars or anything). |
| 18:19 | <Lachy> | TabAtkins, most of the time, you don't need an <article> around the whole lot |
| 18:19 | <Lachy> | Use <div> for that, or maybe the proposed <content> element if that gets added to the spec |
| 18:20 | <TabAtkins> | Yah, I was wondering about explicitly blessing <article> for the proposed purpose of <content>/<main>. |
| 18:20 | <Lachy> | no |
| 18:21 | <mpilgrim> | done. http://diveintohtml5.org/about.html |
| 18:22 | <mpilgrim> | Philip`: what spec are they violating? |
| 18:22 | <Lachy> | nested <article> elements need to be related to the parent article; the canonical example is reader comments |
| 18:22 | <miketaylr> | TabAtkins: I just looked at the source of html5doctor.com, and they're wrapping the main content in <section>, and the comments in <article> |
| 18:23 | <TabAtkins> | Lachy: So in that case, you'd wrap the blog post and the comments in an <article>, so the comments can be wrapped in <article>s and relate properly? |
| 18:23 | <Lachy> | yes |
| 18:24 | <Lachy> | I thought there was an example in the spec illustrating that, but I can't see it. Anyway, read the element definition. it explain it sufficiently |
| 18:24 | <TabAtkins> | miketaylr: Thanks. I think my mental model is broken; I tend to think of <section> as automatically subordinate to <article>. |
| 18:25 | Lachy | checks what html5doctor is doing... |
| 18:25 | <miketaylr> | TabAtkins: my mental model changes every other day. :S |
| 18:25 | <Lachy> | damn. I will get that fixed. The use of <section id="content"> is wrong. |
| 18:26 | Lachy | makes a note to contact Bruce about it |
| 18:26 | <TabAtkins> | Can you explain why it's wrong, Lachy? |
| 18:27 | <Lachy> | yes, because it affects the outline, so basically if a section doesn't have a heading (or at least, couldn't have one), then it generally shouldn't be using <section> |
| 18:27 | <miketaylr> | *lightbulbs turn on* |
| 18:27 | <Lachy> | I can't think of any cases where a <section> wouldn't have a heading, but I'm not confident enough to say that it never happens. But it would be rare if it did. |
| 18:28 | <Lachy> | miketaylr, does that mean my explanation helped you understand it? |
| 18:28 | <tantek> | in print, sometimes sections are simply delineated with horizontal rules, no heading |
| 18:28 | <miketaylr> | yes, . |
| 18:28 | <miketaylr> | sorry, should be more explicit. it's helpful, Lachy |
| 18:29 | <TabAtkins> | Hrm. That still seems like a significant and semantic 'section' of the page, though, even if it doesn't have a heading. It *could* have one, say, "Articles". |
| 18:30 | <Lachy> | tantek, in the cases I've seen, where a book has chapters, which are themselves divided by horizontal rules, I'd expect the chapter to be one <section> and then simply divide it with <hr> |
| 18:31 | <tantek> | the remaining separator markup (e.g. <hr>) in HTML is a bit of an anachronism |
| 18:31 | <tantek> | originally <p> was just a separator as well |
| 18:31 | <Lachy> | IIRC, I think Hitchhiker's Guide is an example of a book that does that (though I don't have it here to check, and I could be thinking of another book) |
| 18:31 | <Lachy> | I know, but that was fixed long ago |
| 18:31 | <tantek> | but now people use <p>...</p> <p>...</p> |
| 18:31 | <tantek> | similarly, <hr> is archaic |
| 18:32 | <tantek> | it will be better to use <section>...</section> <section>...</section> |
| 18:32 | <Lachy> | <hr> is simple and practical |
| 18:32 | <tantek> | and CSS for styling/border effects |
| 18:32 | <tantek> | Lachy, so was the <p> separator |
| 18:32 | <tantek> | no different conceptually |
| 18:32 | <tantek> | it will eventually go the same way |
| 18:34 | <TabAtkins> | Hrm. If <hr> does mark an implicit section break, how should it play with the outline algorithm whene using implicit sectioning via <h*>? Just close the latest implicit section? |
| 18:35 | <Lachy> | no, it doesn't close a section. It just divides two parts of it |
| 18:36 | <TabAtkins> | Same question, then - does it divide the lowest section only? |
| 18:37 | sylvaing2 | humbly wonders how the masses of web authors will get <section> straight if this audience cannot |
| 18:37 | <Lachy> | I understand where you're coming from, as I once argued the same thing many years ago for XHTML2, before HTML5 started, but I've since come around and become more pragmatic about it |
| 18:38 | <TabAtkins> | I'm just nitpicking, really. |
| 18:38 | <Lachy> | TabAtkins, I don't really understand the question. It's a thematic break between two parts of the section. |
| 18:38 | <TabAtkins> | The implicit sectioning algorithm is supposed to be only for legacy content anyway. |
| 18:39 | <Lachy> | the implicit sectioning algorithm isn't affected by <hr> at all, but no, it's not only for legacy content |
| 18:39 | <mpilgrim> | econhelp/sbo |
| 18:39 | <TabAtkins> | Lachy: Given "<h1>foo</h1>content<h2>bar</h2>content<hr>content", does the <hr> divide the implicit section started by the <h1>, or the section started by the <h2>? |
| 18:39 | <mpilgrim> | grr |
| 18:40 | <Lachy> | Eventually, people will relise how impractical it is to have to surround every little section with a <section> element, and begin to use the numbered heading elements more wisely within sections. |
| 18:41 | <TabAtkins> | Lachy: I agree and use my headings and sections that way now. |
| 18:41 | <Lachy> | TabAtkins, the "content<hr>content" is all part of the implied section, since <hr> doesn't affect the algorithm at all. It's just treated the same as <p> or <div> or whatever else as far as the algorithm is concerned |
| 18:41 | <TabAtkins> | K, that's what I was thinking. |
| 18:42 | <Lachy> | that's actually one of the benefits of retaining the mixed model sectioing system, rather than going the pure-sectioning-based XHTML2 model |
| 18:45 | <Lachy> | damn, HTML5 doctor is totally misusing lots of markup :-( |
| 18:46 | <Lachy> | looks like we really do need to have a <content> element, if only to stop the misuse of <section> |
| 18:46 | <TabAtkins> | RT: Hrm. That still seems like a significant and semantic 'section' of the page, though, even if it doesn't have a heading. It *could* have one, say, "Articles". |
| 18:47 | <TabAtkins> | That it doesn't seems to be more of a stylistic choice than a semantic one. |
| 18:48 | <TabAtkins> | So I'm still not sure why html5doctor shouldn't be using a <section> theree. |
| 18:54 | <Lachy> | TabAtkins, possibly, if the section were just containing the articles, and it did have an "Articles" heading, it would be right. But in html5doctor's case, it also contains the sidebar |
| 18:54 | <Lachy> | so it's being used as a general purpose container element |
| 18:54 | <TabAtkins> | Oh it does? Sorry, didn't notice that. That *is* an abuse then. |
| 18:54 | <TabAtkins> | Carry on. |
| 18:55 | <Lachy> | it's unfortunate that <section> is becoming the new <div> :-( |
| 18:55 | <TabAtkins> | Agreed. |
| 18:55 | <Lachy> | I think I need to write an article about this to clear up the issues. |
| 18:55 | <Lachy> | and tell people not to be afraid of <div>! |
| 18:56 | <krijnh> | But <div> kills kittens! |
| 18:56 | <miketaylr> | I'm allergic to cats, so I don't mind. |
| 18:56 | <TabAtkins> | I think it's the general "semantics are awesome, and <section> is more semantic than <div>, thus it is more awesome, thus I will use it everywhere" idea. |
| 18:57 | <TabAtkins> | Same thing that makes people use <em> when they *really* mean <i>. |
| 18:58 | <Lachy> | krijnh, if that were true, it must be the least efficient killing method ever. I still see cats around every so often |
| 18:58 | <krijnh> | Then people don't use div enough :) |
| 18:59 | <krijnh> | So your article is extra welcome |
| 18:59 | <Lachy> | what a great campaign that would be: Use <div>, Help Kill the Kittens! |
| 18:59 | <TabAtkins> | Yeah, I'd welcome an article, Lachy. Would be good to point people to. |
| 18:59 | <Darxus> | Does HTML5 have ways for me to make it easier for a speech browser to skip the text to speech conversion by providing the speech for it? |
| 19:00 | <Lachy> | Darxus, what do you mean? |
| 19:00 | <TabAtkins> | You mean like saying "this audio file is a speech version of this element on the page"? |
| 19:00 | <Darxus> | TabAtkins: Exactly. |
| 19:01 | <Lachy> | Darxus, no, you shouldn't do that. text-to-speech has many navigational advantages over a pre-recorded audio file |
| 19:01 | <TabAtkins> | That sounds like a wonderful way to confuse the crap out of speech browsers the moment the content changes and the audio isn't updated. |
| 19:01 | <gsnedders_> | Can anyone think of anything where the narrator is the antagonist? |
| 19:01 | <Darxus> | I was thinking about http://en.wikipedia.org/wiki/Wikipedia:WikiProject_Spoken_Wikipedia - they just record a single ogg of the entire page. And I was thinking that might be less useful than TTS due to ability to navigate. |
| 19:01 | <Lachy> | gsnedders_, do you mean, like in a play? |
| 19:01 | <TabAtkins> | I expect that aural browsers would quickly ignore such a feature. |
| 19:02 | <gsnedders> | Lachy: In any sort of literature |
| 19:02 | <Darxus> | TabAtkins: Then what is the point of http://en.wikipedia.org/wiki/Wikipedia:WikiProject_Spoken_Wikipedia ? |
| 19:02 | <TabAtkins> | gsnedders: I know I've read a book or short story like that, but the title isn't coming to me. |
| 19:02 | <Lachy> | gsnedders, I think there are some cartoons that do that sometimes. |
| 19:02 | <TabAtkins> | Darxus: People like doing dumb things? Spoken *wikipedia* is *extra* dumb, because Wikipedia is likely to change underneath you constantly. |
| 19:02 | <gsnedders> | Lachy: cartoons aren't proper lit. :P |
| 19:03 | <Darxus> | Hehe. |
| 19:03 | <Lachy> | gsnedders, I don't know of any books that have a narrator in the story itself |
| 19:04 | <Darxus> | Anybody know the best way for me to access a web page via text to speech under ubuntu? |
| 19:04 | <Lachy> | Darxus, there are some advantages to providing a recorded version of a relatively stable page, so people can listen to it on their MP3 players |
| 19:04 | <Lachy> | much like an Audiobook |
| 19:06 | <Lachy> | but it shouldn't be presented as an accessible version intended for the blind. It should be an option for everyone, and the text version needs to remain accessible |
| 19:07 | <TabAtkins> | Lachy: it's decently common to have a protagonist also be the narrator. |
| 19:07 | <Lachy> | TabAtkins, I don't read many books |
| 19:07 | <TabAtkins> | Ah, k. I do. ^_^ |
| 19:08 | <TabAtkins> | gsnedders: I think what I was thinking of was a story where the narrator was *presenting* themselves as the protagonist, even though they filled a more traditional villain role when you stepped away. |
| 19:08 | <Lachy> | In fact, the last set of Novels I've read in a long time is the Harry Potter series, and a few years before that, I'd read The Hobbit. |
| 19:09 | <gsnedders> | TabAtkins: How were they not the protagonist? The protagonist is merely the primary character… |
| 19:09 | <gsnedders> | (The protagonist isn't inherently the hero, they can be the evil demon) |
| 19:09 | <TabAtkins> | Sorry, using the terms as hero/villain proxies. |
| 19:09 | gsnedders | sends TabAtkins back to school |
| 19:10 | tantek | catches up on a bit of scrollback. |
| 19:10 | <TabAtkins> | Man, whatev. |
| 19:10 | <tantek> | Yes, divitis will simply give way to sectionitis in HTML5, as <section> is the "new shiny" that authors will adopt. |
| 19:10 | <gsnedders> | tantek: Short version: we were discussing useful stuff, then I came in. |
| 19:11 | <tantek> | Lachy, I agree with you that <hr> represents a thematic break. That's practical and simple. I disagree that it has anything to do with a break in a section - that just confuses the matter. |
| 19:12 | <Lachy> | I don't understand the distinction you're trying to make |
| 19:16 | <jgraham> | gsnedders: Possibly Vernon God Little, but I didn't actually finish reading it |
| 19:16 | <TabAtkins> | Lachy: I think he's referring to something like my confusion, that saying it "breaks a section" seems to imply that an <hr> implies subsections before and after it. |
| 19:20 | <Lachy> | oh, yeah, that was wrong |
| 19:38 | <annevk2> | I always wondered why SVG was such a mess: http://www.w3.org/mid/1039235648.20090819175847⊙wo |
| 19:39 | <annevk2> | Not that HTML is much better in this regard... |
| 19:41 | <TabAtkins> | I sort of laughed about that too. Seems like it would have been easier/better to set a single convention, then alias the other convention if necessary. |
| 19:49 | <annevk2> | MathML did a pretty good job at staying consistent with HTML |
| 19:49 | <annevk2> | until they got definitionURL |
| 19:49 | <annevk2> | not sure how that happened |
| 19:49 | <Hixie> | probably the same way HTML managed to stay consistent with HTML until, sy, http-equiv |
| 19:49 | <Hixie> | s/sy/say/ |
| 19:51 | <annevk2> | or <img> vs <video>? |
| 19:52 | <annevk2> | though in text/html you could use <image> I suppose at the cost of a validation error :) |
| 19:52 | <annevk2> | not sure if that speaks in favor of the HTML format |
| 19:52 | <Hixie> | not sure what you mean about img vs video |
| 19:53 | <annevk2> | abbreviation |
| 19:53 | <Hixie> | html had different ways of naming elements from the begining |
| 19:54 | <annevk2> | imagine you'd introduce elements for images, video, and audio today |
| 19:54 | <annevk2> | though maybe you don't think they belong to the same set |
| 20:03 | <Hixie> | mpilgrim_: "The default font is 10px sans-serif. Sizes in em or percentages are measured against the default font." is wrong |
| 20:06 | <Hixie> | it's relative to the computed value of the font on the <canvas> element |
| 20:07 | <annevk2> | mpilgrim_, are you planning on updating it online or will we have to wait until early 2010? |
| 20:10 | <annevk2> | Hixie, you should include this comic in the Web Database introduction section: http://xkcd.com/327/ |
| 20:12 | <Hixie> | hehe |
| 21:18 | <mpilgrim> | is this text correct now? http://diveintohtml5.org/canvas.html#relative-font-size |
| 21:18 | <mpilgrim> | (annevk2 or annevk3 or whomever) |
| 21:19 | <ttepasse> | mpilgrim, something different: <div id=body>? |
| 21:19 | <mpilgrim> | damn, i was hoping no one would notice that |
| 21:19 | <mpilgrim> | styling the body element is... difficult |
| 21:19 | <ttepasse> | Next on my list: the <dl>s |
| 21:19 | <mpilgrim> | mu |
| 21:20 | <ttepasse> | hihi |
| 21:20 | <annevk2> | mpilgrim, I think so |
| 21:20 | <mpilgrim> | (c.f. http://www.propylon.com/news/ctoarticles/Zen_and_the_Art_of_Motorcycle_Manuals_20020822.html ) |
| 21:20 | <mpilgrim> | ok, thanks |
| 21:21 | <mpilgrim> | the answer to your other question is that i'll be updating diveintohtml5.org, but i'm not sure about the version on oreilly.com |
| 21:21 | <mpilgrim> | i should probably ask them to republish just with this change, since it's a technical error |
| 21:21 | <mpilgrim> | they will not be updating their excerpt for new content |
| 21:22 | <mpilgrim> | the rest of the chapter will discuss transformations, animation, and using the explorercanvas library for IE compatibility |
| 21:22 | <mpilgrim> | oh, and toDataURL or whatever it's called |
| 21:23 | <annevk2> | that's the name |
| 21:24 | <annevk2> | in other news, if people could help out fill out tables for the other browsers: http://wiki.whatwg.org/wiki/Web_Encodings |
| 21:24 | <annevk2> | I got the slightly overambitious goal of solving the encoding problem |
| 21:26 | <Dashiva> | annevk2: Is there simple test to run? |
| 21:26 | <annevk2> | I wish |
| 21:27 | <annevk2> | sgalineau, any chance you could help out with http://wiki.whatwg.org/wiki/Web_Encodings for Internet Explorer? |
| 21:28 | <krijnh> | Is there a problem then? :) |
| 21:28 | <ttepasse> | Is there a reason, why <mark> is just phrasing content? |
| 21:32 | <TabAtkins> | ttepasse: because its primary purpose is to mark frex search terms in a page. |
| 21:33 | <ttepasse> | I was thinking more about the usage in blockquotes. |
| 21:37 | <shepazu> | TabAtkins: "frex"? |
| 21:37 | <TabAtkins> | frex = for example |
| 21:39 | <TabAtkins> | ttepasse: Oh, so you wanna <mark> a block of markup within a <blockquote>? |
| 21:40 | <ttepasse> | The concrete use case were two paragraphs, yes. |
| 21:44 | <TabAtkins> | Hrm. FF respects styling when printing to the point of cutting off ordinary text in a fixed-width container that is wider than the page. |
| 21:44 | <TabAtkins> | That's a little annoying. |
| 21:45 | <TabAtkins> | Probably required, but still. |
| 21:47 | <TabAtkins> | annevk2: Was there a point to the email you just sent, or is just a summary of things? |
| 21:50 | <TabAtkins> | annevk2: Not trying to be rude, just wondering. ^_^ |
| 21:50 | <annevk2> | i hit the wrong button? |
| 21:50 | <annevk2> | oh and it arrived two times? sweet |
| 21:50 | <annevk2> | wtf |
| 21:50 | <krijnh> | You prutser you |
| 21:51 | <TabAtkins> | Ah, makes a lot more sense now. |
| 21:51 | <shepazu> | "Due to the cheer volume of e-mails on this list"... either Hixie thinks the HTML list is a happy place, or it's full of cheerleaders, or he made a slight typo... possibly all 3 |
| 21:52 | <TabAtkins> | I'm going with the second explanation. |
| 21:55 | <mpilgrim> | annevk2: you should integrate the information/tests from http://coq.no/character-tables/mime/iso-2022/en , http://coq.no/character-tables/mime/euc/en , and http://coq.no/character-tables/mime/locale-specific/en |
| 21:59 | <Hixie> | where's the spec that defines how implementations implement ARIA again? |
| 22:02 | <annevk2> | http://www.w3.org/TR/wai-aria-implementation/ |
| 22:02 | <annevk2> | not sure where the editor's draft is |
| 22:02 | <annevk2> | thanks mpilgrim |
| 22:03 | <poe> | ed è anche ragionevole la dipendenza dalla velocità |
| 22:03 | <poe> | i'm sorry wrong window |
| 22:04 | <Hixie> | http://www.w3.org/TR/2009/WD-wai-aria-practices-20090224/ |
| 22:04 | <Hixie> | thanks |
| 22:05 | <Hixie> | wait that can't be it |
| 22:05 | <Hixie> | the link to the editor's draft is quite wrong |
| 22:05 | <Hixie> | http://www.w3.org/WAI/PF/aria-implementation/ |
| 22:49 | <krijnh> | Shitty connection day :/ |
| 22:50 | <JonathanNeal> | It's not even using of the new HTML5 elements, for starters. I guess this would be best shared with a cross compatibility or css channel. Sorry. |
| 22:53 | <TabAtkins> | What should we be scrutinizing about it, JonathanNeal? |
| 22:55 | <Hixie> | annevk2: did the document pointer stuff change in xhr? |
| 22:57 | <annevk2> | Hixie, what was previously defined did not work for when the interface object was moved around |
| 22:58 | <JonathanNeal> | TabAtkins, I just fouled up where I should have posted it. I've been writing my own normalize.css that I *think* is better than any of the major ones out there. |
| 22:58 | <TabAtkins> | Oh, okay. |
| 22:58 | <JonathanNeal> | They're always trying to re-globalize what everything means instead of actually normalize between the browsers. |
| 22:59 | <JonathanNeal> | I'm hoping we can switch to that from the yui one. However, I ended up removing all of the html5 elements from the document, so it killed the point of having you folks scrutinize my use of any specific html5 elements. |
| 22:59 | <annevk2> | Hixie, I'm not totally clear on whether all the details are correct now to be honest; I have attempted to test it, but some of the details of how document/window interact and "fully active document" make it a bit hard |
| 22:59 | <Hixie> | annevk2: if you could comment on http://www.w3.org/Bugs/Public/show_bug.cgi?id=7373 regarding what the new text for XHR documents should be, that'd be great |
| 23:00 | <annevk2> | Hixie, there's a XMLHttpRequest origin concept |
| 23:00 | <annevk2> | Hixie, "Each XMLHttpRequest object has an associated XMLHttpRequest origin and an XMLHttpRequest base URL." |
| 23:00 | <JonathanNeal> | We're working on making our layouts more robust and outline friendly @ http://madison.thewikies.com/alloy/960_grid.html |
| 23:01 | <TabAtkins> | JonathanNeal: Eh, all of the html5 elements default to margin-less inline elements anyway, so just put whatever you want in your file. |
| 23:01 | <JonathanNeal> | TabAtkins, no they should be block elements in my document, IF they were there. |
| 23:01 | <Hixie> | annevk2: if you could mention that on the bug that'd be awesome |
| 23:01 | <Hixie> | i gotta run |
| 23:01 | <JonathanNeal> | Those layouts in that last grid are cross browser compatible, but still give us a lot of flexability in layouts. |
| 23:01 | <Hixie> | bbiab |
| 23:02 | <annevk2> | done, nn |
| 23:02 | <TabAtkins> | Yeah, but you have to set them like that in current parsers. |
| 23:03 | <JonathanNeal> | Well, of course, but we'll be supporting ie8 for a while, I suspect, so might as well declare the elements and give them the proper style. |
| 23:04 | <JonathanNeal> | Firefox needs them too, I know, but just the css. |
