| 09:24 | <mitsuhiko> | hmm. small bug in html5lib |
| 09:24 | <mitsuhiko> | etree_lxml tries to import lxml.etree as etree twice |
| 09:24 | <mitsuhiko> | however the first import should import lxml.html as etree |
| 09:46 | <Lachy> | whatwg.org is down again |
| 12:17 | <Lachy> | JohnResig, yt? |
| 12:18 | <Lachy> | JohnResig, you might like to CC yourself on this bug http://www.w3.org/Bugs/Public/show_bug.cgi?id=5860 |
| 12:18 | <Lachy> | I'm using bugzilla to track the feature request for selectors api v2 |
| 15:44 | <Philip`> | http://ejohn.org/blog/html-5-data-attributes/ - "With data- attributes you can implement RDFa in HTML, advanced Microformats in HTML, ..." - but data- attributes are specifically intended to *not* be used for those things (i.e. things where some software external to the page infers some meaning from a page's use of data- attributes) |
| 15:54 | <jgraham> | Philip`: I can't imagine that anything the spec has to say about that will stop it from happening. It's such an obvious idea |
| 16:39 | webben_ | wonders whether having script- and data- attributes would be a clean solution. |
| 17:06 | <Philip`> | jgraham: The spec could stop that from happening by removing the data- feature - it's a bad solution to the use-cases if everyone's going to abuse it as a simple get-out-of-validation-free trick |
| 17:21 | <jgraham> | Philip`: Well yes I guess that would work, but it seems a bit drastic. Presumably we could also acknowledge that people are going to see it as a good place to put e.g. Microformat data instead of overloading @title or whatever, and put some suggestions in the psec or the authoring guide to mitigate the bad side effects |
| 17:25 | webben_ | isn't clear why people can't be given an official place to hide extractable data. |
| 17:25 | <webben_> | or what the bad side effects of that would be. |
| 18:56 | <Philip`> | webben_: The problem is that there's no standard for how authors/UAs should handle specific data- attributes, so there will be lots of interoperability problems once multiple parties try to interoperate with the same data; and there's nothing to attempt to prevent name collisions, if two people/tools independently decide to process the same attribute in different ways |
| 18:57 | <webben_> | Philip`: Seems to me that the idea of data- was for multiple parties not to use them. |
| 18:58 | <webben_> | Philip`: as for name collisions with microformat data, well, that's the same issue as class |
| 18:58 | <webben_> | if class structures aren't good enough to solve that, resurrect profile |
| 18:58 | <webben_> | Philip`: and note that the problem already happens without data- |
| 18:59 | <webben_> | the abbr title issue is precisely an issue of multiple parties using the title attribute for different purposes |
| 19:00 | <Philip`> | webben_: It was intended to be used only in single-party situations, like when a page contains the data and the scripts to act on that data; but people seem to be failing to notice that, and only seeing the 'you can use any attributes you want and the validator won't complain' aspect of it |
| 19:00 | <Dashiva> | Not like it wasn't possible to use class and title as opaque strings already... |
| 19:00 | webben_ | is unsurprised. But then I don't think the validator is that useful unless you're interested in what it's validating, if you see what I mean. |
| 19:00 | <webben_> | that is to say, people invent attributes already |
| 19:01 | <webben_> | the fact that they don't validate doesn't seem to deter them much |
| 19:01 | webben_ | says this as someone who argues strongly against people using HyperText MadeUp Language. |
| 19:01 | <Philip`> | Dashiva: Doing it with class feels like an ugly hack, because people know class is meant to be used to associate CSS with an element, and it gets messy if your data includes spaces, so many people seem to stay away from abusing class like that |
| 19:01 | <Philip`> | Dashiva: and doing it with title means you get ugly tooltips all over your page |
| 19:02 | <Dashiva> | Philip`: You mean they "know" it's meant to be used for CSS |
| 19:02 | <webben_> | class isn't just intended to be used for CSS |
| 19:02 | <webben_> | (or even primarily) |
| 19:03 | <Philip`> | Dashiva: whereas using data- for embedding custom data seems like a perfectly sensible justifiable thing to do because that's the whole reason it was added to HTML5, so it's a good place to stick all your microformats and RDFa into |
| 19:03 | <Dashiva> | So people will do what they're already doing in a cleaner way |
| 19:03 | <webben_> | but that's not the reason it was added |
| 19:03 | <webben_> | it was added for people who wanted to dump data for use in on-page JS |
| 19:03 | Dashiva | looks up the data type of @class |
| 19:04 | <webben_> | cdata whitespace separated. |
| 19:04 | <Philip`> | Dashiva: They will use the slightly ugly data- way instead of trying to reuse appropriate semantics that are already supported by HTML and instead of trying to standardise proper extensions to the language |
| 19:04 | <Philip`> | s/They/Some of them/ |
| 19:04 | <webben_> | I think the problem of using generic solutions rather than particular solutions is an unavoidable authoring error in this stack. |
| 19:05 | <Philip`> | webben_: It wasn't intended for CSS, but I'm guessing that that's how pretty much all web developers think of it, though I have zero justification other than that's how I tend to think of it :-) |
| 19:05 | <webben_> | e.g. use of divs and spans instead of more specific elements. |
| 19:06 | <webben_> | Philip`: I think you'll find web developers fall into various significant groups wrt class. |
| 19:06 | <Dashiva> | Just in case anyone hasn't looked it up already |
| 19:06 | <Dashiva> | The class attribute has several roles in HTML: * As a style sheet selector (when an author wishes to assign style information to a set of elements). * For general purpose processing by user agents. |
| 19:06 | <webben_> | a) people who barely know it exists and use presentational markup / style attributes instead. |
| 19:06 | <webben_> | b) people who uses presentational classes (".red") |
| 19:06 | <webben_> | c) people who use semantic class naming |
| 19:07 | <Philip`> | webben_: What about people who use semantic class naming but use it solely as a way of attaching styling to elements? |
| 19:07 | <takkaria> | I don't see the difference between b and c. class names are opaque so there's no practical difference |
| 19:08 | <webben_> | takkaria: There's a heck of a lot of difference if you have to work with the code. |
| 19:08 | <Philip`> | I write <div class="header"> instead of <div> because I want to apply certain header-like styling to the element; I would't bother with the 'semantic' name if I wasn't going to style it |
| 19:08 | <webben_> | takkaria: also semantic class names end up being microformat-prototypes. |
| 19:08 | <Dashiva> | class="data-apple=pie,computers,records" |
| 19:08 | <Philip`> | *wouldn't |
| 19:09 | <Philip`> | Dashiva: Then you have to write a parser when you have multiple key/value pairs on an element, and it gets all yucky |
| 19:10 | <webben_> | class is certainly under discussion as a title alternative in the microformats community; it's reconcilable with the spec and easier to implement than natural language processing. |
| 19:10 | <webben_> | it's generally felt to be icky however. |
| 19:11 | <Dashiva> | var classData = {}; var classRe = /([^\s=]+)=(\s+)/g; while (var res = re.exec(el.class)) { classData[res[1]] = res[2]; }; return classData; |
| 19:11 | <webben_> | s/generally/widely/ |
| 19:11 | <Philip`> | (In some real code I've written for some site, I just used <a href="..." _foo="..." _bar="..."> because that's the easiest solution and who cares about validators anyway) |
| 19:11 | <Dashiva> | It's the same work you do parsing the query string, indicentally |
| 19:11 | <Dashiva> | Just split on space instead of & |
| 19:11 | webben_ | would suggest that if you do use custom attributes you namespace them. |
| 19:11 | <Philip`> | Dashiva: Good luck getting an average web developer to understand (never mind write) code like that :-p |
| 19:11 | <Dashiva> | Philip`: See above comment about query string |
| 19:11 | <webben_> | Philip`: average web developers don't need to understand such code. |
| 19:11 | <takkaria> | webben_: I'm just sceptical of anyone who says something has a meaning independent of its behaviour. if you do <div class="header"> instead <div class="big"> but the style rule is the same between them, what's the difference? |
| 19:12 | <Philip`> | Dashiva: You parse the query string by reading $_GET on the server side |
| 19:12 | <webben_> | takkaria: What it means to the people working on the code. |
| 19:12 | <Dashiva> | Philip`: Have fun with your web 0.9 app then |
| 19:12 | <webben_> | takkaria: Maybe it's difficult to grok unless you've worked in teams that use semantic naming /and/ have tried to make sense of random people's code on IRC. |
| 19:13 | <Philip`> | Dashiva: Pfah, I'll use an AJAX request to send the query string to a PHP script that parses it and returns a JSON representation |
| 19:13 | <Philip`> | That should be sufficiently Web 2.0 |
| 19:13 | <Dashiva> | So do the same for class :P |
| 19:13 | <webben_> | takkaria: plus, you'll often use class names for scripting, so you're attaching multiple behaviors to the same "semantic" target. |
| 19:13 | <Philip`> | Dashiva: That would be quite inefficient, since there's only one query string per page but lots of class names |
| 19:13 | <takkaria> | webben_: ok, I think I'm just being overly hostile towards people's use of the word "semantic", I don't think my point really applies to the current discussion :) |
| 19:14 | <Dashiva> | Philip`: Sounds even more web 2.0 to me |
| 19:15 | <Dashiva> | It sounds like you never experienced Web 2.0 <blink> or Web 2.0 alert() |
| 19:15 | <Philip`> | Dashiva: I suppose the inefficiency can be fixed in Web 2.0 SP1 |
| 19:16 | <Dashiva> | (cf. http://cheese.blartwendo.com/web21-demo.html) |
| 21:51 | <john__m> | is there a preference in html5 using <embed> and <object> for displaying inline flash content? |
| 21:53 | <john__m> | whoops...a preference between using <embed> or <object>... |
| 22:00 | <Hixie> | Philip`: data- is a good place for microformats only so long as you don't want the browsers ever to support those microformats natively |
| 22:06 | <webben_> | so not useful for microformats |
| 22:09 | <webben_> | john__m: not afaict from the draft proposals; contrast applet which is obsoleted http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#sandboxPluginApplet |
| 22:13 | <takkaria> | Hixie: you did some stats a while back on what the average number of attributes on tags was |
| 22:13 | <takkaria> | Hixie: at least, I think you did. is it still around? |
| 22:14 | <john__m> | webben_: to me the spec only seems to differ in the availability of fallback content, at least I can't see how <embed> is supposed to provide fallback |
| 22:18 | <webben_> | john__m: the draft says: "The embed element has no fallback content. If the user agent can't display the specified resource, e.g. because the given type is not supported, then the user agent must use a default plugin for the content. (This default could be as simple as saying "Unsupported Format", of course.) " |
| 22:19 | <webben_> | john__m: in terms of real-world text/html clients, some support alt on embed, and there's also a noembed element |
| 22:24 | <john__m> | webben_: thanks, somehow I read right over that paragraph in the <embed> spec |
| 22:36 | <annevk> | the idea is that the format itself is accessible |
| 22:36 | <annevk> | of course, Flash is better avoided :) |
| 22:39 | <webben_> | s/is/should be/ ? |
| 22:56 | <Philip`> | takkaria: http://canvex.lazyilluminati.com/misc/stats/ has some fairly rubbish data including number of attributes per tag |
| 23:09 | <john__m> | annevk: maybe you should call my client and tell them that – my attempts, obviously, failed :) |
| 23:56 | <annevk> | Hixie, status of http://www.whatwg.org/specs/web-workers/current-work/ is probably wrong, it's not really a "Draft Recommendation" |