| 02:22 | <zcorpan> | jgraham: when it comes to generating table descriptions, i think a good first step would be to include the number of rows and columns, and where the table headers are |
| 02:27 | <zcorpan> | "Table with 19 rows and 7 columns. The first two rows contain headers. The first row and the first column contain merged cells." |
| 02:27 | <zcorpan> | http://projectcerbera.com/web/study/2007/tables/clark2006/05-housing/original |
| 02:29 | <zcorpan> | hmm actually that table has merged cells on the first two rows and the first two columns |
| 02:29 | <zcorpan> | but i guess the top left cell should be ignored |
| 02:30 | <zcorpan> | or maybe empty cells should be ignored |
| 02:31 | <zcorpan> | maybe it's not so useful to say where there are merged cells |
| 02:31 | <zcorpan> | maybe just stating that it contains merged cells |
| 02:35 | zcorpan | looks at the forming a table algorithm in the spec |
| 02:47 | <zcorpan> | might also be good to announce when there are more than one tbody or when there's a tfoot |
| 03:57 | <MikeSmith> | zcorpan: you still around? |
| 04:01 | <MikeSmith> | sayrer: you got time to chat? |
| 04:07 | <zcorpan> | MikeSmith: yes |
| 04:08 | <MikeSmith> | zcorpan: do you have a local workspace for testing v.nu changes? |
| 04:09 | <zcorpan> | MikeSmith: local workspace? |
| 04:10 | <MikeSmith> | zcorpan: I mean, an svn workspace, so that you can sync up to latest svn revision and then re-run a local v.nu to test changes? |
| 04:11 | <zcorpan> | MikeSmith: ah. no |
| 04:12 | <zcorpan> | i checked out the source on my windows laptop but didn't get it to run |
| 04:12 | <zcorpan> | i probably don't have JDK on my mac |
| 04:12 | <MikeSmith> | ok, no problem |
| 04:13 | <zcorpan> | is there something you'd like me to test? |
| 04:13 | <MikeSmith> | I'm adding frameset to the actual schema |
| 04:13 | <MikeSmith> | and wanted to make sure I've not muffed it up |
| 04:14 | <MikeSmith> | I have my own simple tests for it, but wanted to double-check |
| 04:16 | <zcorpan> | ping me when it's live in v.nu and i can try to break it |
| 04:16 | <MikeSmith> | OK |
| 04:20 | <MikeSmith> | zcorpan: anyway, the only difference my change will introduce is that when you check a document that has <frameset>, the "Error: Element frameset not allowed as child of element html in this context. (Suppressing further errors from this subtree.)" message will be suppressed |
| 04:21 | <MikeSmith> | oh, and it will actually report any errors in the subtree |
| 04:22 | <zcorpan> | MikeSmith: will it complain about required children missing (i.e. the <body>)? |
| 04:25 | zcorpan | guesses not |
| 04:28 | <MikeSmith> | zcorpan: you guess right, it won't |
| 04:28 | <zcorpan> | MikeSmith: have you tested noframes before and after the frameset? |
| 04:29 | <MikeSmith> | zcorpan: nope |
| 04:30 | <MikeSmith> | but if you give a test, I will add it and test it before I check in |
| 04:31 | <zcorpan> | html4 only allows noframes inside frameset, but the html5 parser inserts noframes to head or html for before and after respectively |
| 04:32 | <zcorpan> | <!doctype html><title>noframes</title><noframes></noframes><frameset><noframes></noframes></frameset><noframes></noframes> |
| 04:32 | <zcorpan> | i guess it should whine about the first and last |
| 04:34 | <zcorpan> | and missing frame or frameset child |
| 04:37 | <MikeSmith> | zcorpan: OK, this is what I get: |
| 04:37 | <MikeSmith> | http://pastebin.com/m4ba0c569 |
| 04:37 | <MikeSmith> | so I guess I need to add <noframes> as a valid child of <head> |
| 04:40 | <zcorpan> | MikeSmith: why? |
| 04:40 | <zcorpan> | MikeSmith: html4 doesn't allow noframes in head |
| 04:41 | <MikeSmith> | ah, OK |
| 04:41 | <MikeSmith> | so what should it be reporting for that case? |
| 04:43 | <zcorpan> | MikeSmith: what you pasted seems correct |
| 04:45 | <MikeSmith> | zcorpan: OK |
| 04:46 | <zcorpan> | MikeSmith: maybe it's not so useful to assert that the elements other than the top-most frameset being obsolete |
| 04:58 | <MikeSmith> | dglazkov: great to finally have http basic auth working in chrome on linux |
| 05:06 | <MikeSmith> | zcorpan: btw, I have an open bugzilla issue for keeping track of ideas around how to do better reporting for obsolete elements |
| 05:07 | <MikeSmith> | and obsolete attributes |
| 05:07 | <MikeSmith> | http://bugzilla.validator.nu/show_bug.cgi?id=481 |
| 05:08 | <dglazkov> | MikeSmith: I take full credit for this. |
| 05:08 | <dglazkov> | MikeSmith: what wasn't working again? |
| 05:08 | <dglazkov> | :) |
| 05:08 | <MikeSmith> | heh |
| 05:08 | <MikeSmith> | dglazkov: I think it just wasn't implemented at all until 190 |
| 05:08 | <MikeSmith> | anyway, it's still only implemented so far for linux, not Mac |
| 05:09 | <MikeSmith> | dglazkov: hey, btw and just fyi - http://code.google.com/p/chromium/issues/detail?id=15422 |
| 05:11 | <othermaciej> | MikeSmith: so would the validator report attributes or elements as obsolete instead of unknown? |
| 05:11 | <othermaciej> | that would be neat |
| 05:12 | <MikeSmith> | othermaciej: yeah, it does that already for a number of elements -- just elements that were in HTML4, but not in HTML5 |
| 05:12 | <MikeSmith> | so, it doesn't do it for <marquee>, but does for <big>, etc. |
| 05:13 | <MikeSmith> | except we didn't have <frameset> and <noframes> and <basefont> in there |
| 05:13 | <sayrer> | "warning <big> is far too short, please use a style attribute" |
| 05:13 | <MikeSmith> | sayrer: heh |
| 05:13 | <MikeSmith> | othermaciej: so all that I'm changing now is just to add those |
| 05:14 | <MikeSmith> | sayrer: so is it your position that validators should not report anything as obsolete? |
| 05:14 | <MikeSmith> | or that we shouldn't have validators at all? |
| 05:14 | <sayrer> | I am totally in favor of lint tools |
| 05:14 | <sayrer> | I'm not so sure about a hard line between valid/invalid |
| 05:15 | <sayrer> | I gather I'm in good company on that one |
| 05:15 | <MikeSmith> | sayrer: well, you are in company, but not sure if it's necessarily "good" company (scare quotes intentional) |
| 05:15 | <sayrer> | I was thinking of a tbl presentation ;) |
| 05:16 | <othermaciej> | MikeSmith: I'm not sure <marquee> is "obsolete" in quite the same way |
| 05:16 | <MikeSmith> | (scare quotes seem to be the trendy thing to do, so I'm trying to use them more frequently) |
| 05:16 | <MikeSmith> | othermaciej: yeah, true |
| 05:16 | <othermaciej> | MikeSmith: don't you mean "scare" quotes? |
| 05:16 | <MikeSmith> | heh |
| 05:16 | <othermaciej> | sayrer: I'm dubious about the value of a normative spec defining the behavior of lint tools |
| 05:16 | <sayrer> | I think that's what he "means" |
| 05:17 | <sayrer> | othermaciej: me too, that's why I don't like the current author conformance requirements |
| 05:17 | <othermaciej> | sayrer: however, hsivonen made the plausible argument that having a certain common level of baseline rules is an interoperability benefit for authoring tools and validators |
| 05:17 | <sayrer> | since there are many rules that are basically lint tool kind of things |
| 05:17 | <MikeSmith> | we should have double scare quotes -- e,g., ""working group"" -- to indicate an extra amount of disdain |
| 05:17 | <othermaciej> | that's the only really convincing argument I have heard for why such things make sense as conformance requirements |
| 05:18 | <othermaciej> | sayrer: do you think the spec should contain any authoring conformace requirements? |
| 05:18 | <Dashiva> | MikeSmith: Shouldn't you use a different quote set for one of them, to avoid it parsing as "", working group, ""? |
| 05:18 | <MikeSmith> | heh |
| 05:18 | <othermaciej> | sayrer: it's not totally clear to me if you doubt the value of all of them or only some? |
| 05:18 | <othermaciej> | MikeSmith: I would think nested scare quotes would neutralize |
| 05:19 | <MikeSmith> | ah yeah, true |
| 05:19 | <othermaciej> | MikeSmith: since in general "foo" means 'people call it foo, but I don't really think it is, I'm just using their term under protest' |
| 05:19 | <sayrer> | othermaciej: some rules seem to be in place because the markup is "presentational" |
| 05:19 | <MikeSmith> | you can use them to quote somebody else's use of scare quotes -- to show disdain for the fact that they are using scare quotes |
| 05:20 | <othermaciej> | sayrer: are those the only kinds of rules you don't like? |
| 05:20 | <MikeSmith> | sayrer: very true, and not everybody is in agreement about that class of constraints |
| 05:20 | <MikeSmith> | e.g, the presentational attributes on <table> |
| 05:20 | <othermaciej> | "make presentational markup conforming" is a pretty clear position and worth discussing on that basis |
| 05:21 | <sayrer> | oh, I think concrete spec text would make it easier to discuss |
| 05:21 | <othermaciej> | I have an easier time reading a few sentences than a whole alternate spec |
| 05:21 | <sayrer> | then there are those things that seem kind of vestigial or ineffective |
| 05:22 | <sayrer> | like @profile and @summary |
| 05:22 | <MikeSmith> | the bulk of the kind of conformance checking that v.nu is doing is simply checks like, "you can't have a <dd> as a child of a <ul>" |
| 05:22 | <othermaciej> | I suspect many others are in that position |
| 05:22 | <sayrer> | those vestigial things hardly seem worth bannign |
| 05:23 | <sayrer> | or declaring invalid |
| 05:23 | <othermaciej> | sayrer: do you think rules like what MikeSmith cited (can't have a <dd> as a child of a <ul>) are worthwhile? |
| 05:23 | <othermaciej> | or more specifically, are they worthwhile as conformance requirements? |
| 05:23 | <sayrer> | yes, that is the class of things that I have a hard time characterizing. a lint tool would clearly want to report "<b><i>foo</b></i>" |
| 05:24 | <sayrer> | to use a really brain dead example |
| 05:24 | <othermaciej> | misnested tags are in some sense a different level of error than structurally sound markup that happens to violate content model rules |
| 05:25 | <MikeSmith> | yeah, <b><i>foo</b></i> gets reported by the parser, not validator code |
| 05:25 | <othermaciej> | I think some people are interested in avoiding presentational markup in their output, and others are not |
| 05:25 | <sayrer> | for sure |
| 05:25 | <othermaciej> | right now the spec is a compromise and therefore doesn't fully address either need |
| 05:26 | <othermaciej> | I wonder if it would make sense to have two classes of conformance to address this |
| 05:26 | <MikeSmith> | "Error: End tag b violates nesting rules." |
| 05:26 | <sayrer> | I am in favor of an authoring guide |
| 05:27 | <MikeSmith> | I think it would make sense to have user-tunable validators |
| 05:28 | <othermaciej> | if we accept Henri's premise that there needs to be a shared set of rules, so that different combinations of content generators and validators can interoperate without large switching costs, then an authoring guide may be insufficient |
| 05:28 | <othermaciej> | I'm not sure if that premise is right |
| 05:29 | <MikeSmith> | there's a market for validators, just like there is a market for browsers |
| 05:29 | <othermaciej> | but it sounds plausible |
| 05:29 | <MikeSmith> | and people place value on validators |
| 05:30 | <othermaciej> | the idea being, my CMS generates markup that is error-free in Validator A, but I decide I like the user interface of Validator B better |
| 05:30 | <othermaciej> | can I switch without being flooded with errors? |
| 05:30 | <MikeSmith> | right |
| 05:30 | <othermaciej> | that seems to be a case where interoperability matters |
| 05:31 | <othermaciej> | so that makes me think that there has to be some shared definition of what counts as content errors |
| 05:31 | <othermaciej> | so it's not a viable position for the WG to completely fail to define authoring conformance |
| 05:31 | <sayrer> | I don't think any of that follows |
| 05:32 | <sayrer> | in particular, I am not suggesting the WG fail to define anything |
| 05:32 | <othermaciej> | I'm not saying you are suggesting that |
| 05:32 | <sayrer> | ok |
| 05:32 | <MikeSmith> | anyway, it does at least seem that there's a fundamental baseline of document-conformance rules that we could get agreement on |
| 05:32 | <othermaciej> | it is now clear to me that you think there should be some definition of what constitutes an error |
| 05:32 | <othermaciej> | and that at the very least, you don't think presentational markup or obsolete but harmless attributes should be in that category |
| 05:32 | <sayrer> | well, there are things that I would like to have attention brought to, as an author |
| 05:33 | <sayrer> | "this may not mean what you think it means" is something I want to know about |
| 05:33 | <MikeSmith> | right |
| 05:33 | <MikeSmith> | e.g., a <dd> as a child of <ul> |
| 05:34 | <sayrer> | well, what is the error you would report for that? |
| 05:34 | <othermaciej> | it's not clear to me what you think should be in that definition, or whether you think those rules should be labeled something other than "conformance", or how you feel about whether they need to be in a separate document from browser conformance rules |
| 05:35 | <sayrer> | 1.) not sure what should be there, probably requires user testing |
| 05:35 | <sayrer> | 2.) don't want the labeled as conformance requirements in the HTML document, somewhere else is fine |
| 05:35 | <sayrer> | 3.) probably separate |
| 05:36 | <sayrer> | MikeSmith: what is the ideal error for <dd> in <ul> ? |
| 05:36 | <othermaciej> | so it's ok to label the rules conformance requirements, but not if they are in the same document as browser conformance requirements? |
| 05:36 | <sayrer> | yes |
| 05:36 | <othermaciej> | I can understand the rest of your position, but not that part |
| 05:37 | <sayrer> | the other conformance requirements in the document have interop ramifications |
| 05:37 | <MikeSmith> | sayrer: I don't know what would be ideal, but at a minimum, the checker should report, "<dd> is not allowed as a child of <ul>" |
| 05:37 | <sayrer> | well, it is allowed |
| 05:37 | <MikeSmith> | and then report what is allowed as a child of <ul> |
| 05:38 | <othermaciej> | hsivonen would argue that validity rules have interop ramifications (between different validators and different content generators) |
| 05:38 | <sayrer> | I find that position pretty circular |
| 05:38 | <othermaciej> | I don't see how it's circular |
| 05:39 | <othermaciej> | the idea is that you can switch content generating tools without changing validators, or vice versa |
| 05:39 | <othermaciej> | I think it's a much less important form of interoperability than browser <--> content |
| 05:40 | <othermaciej> | but being able to switch out pieces independently is pretty much what interoperability means |
| 05:40 | <MikeSmith> | sayrer: OK, if I get your point, the error might more precisely be, "using <dd> as a child of <ul> is probably not going to have the effect you might be expecting" |
| 05:40 | <MikeSmith> | sayrer: "<dd> as a child of <ul> is probably not something you want to do" |
| 05:41 | <sayrer> | "we need this rule so the things that check rules will have a rule" |
| 05:42 | <othermaciej> | I think a more fair presentation of the position would be "we need rules about what is an error so that content producers and tools that check for content errors can agree on what is an error" |
| 05:43 | <othermaciej> | you could say "tools that check for content errors" should not label anything they report as errors, but the same reasoning applies if you call them "errors" or "conditions that indicate the author may not have said what he meant" or whatever |
| 05:44 | <othermaciej> | or "warnings" |
| 05:47 | <sayrer> | validator interop is not something the w3c is chartered to |
| 05:48 | <sayrer> | to do |
| 05:49 | <sayrer> | I am not even sure it's desirable, but if it is, every validator implementor will rush to become Rec FooValidator2015 or whatever |
| 05:49 | <sayrer> | I suppose there's a subtext of everyone being paranoid about rogue additions to the language |
| 05:49 | <sayrer> | but I don't think these rules are going to help that |
| 05:52 | <othermaciej> | I could buy that validator interop is not an important goal |
| 05:53 | <sayrer> | it would certainly be easier to suss out if the author conformance rules had clear, uniform motivations |
| 05:53 | <othermaciej> | so far, the one validator developer who has spoken up thinks it is |
| 05:53 | <othermaciej> | they do seem to have different motivations |
| 05:54 | <MikeSmith> | sayrer: it might also help if we used the term "document conformance" instead of "authoring conformance" |
| 05:54 | <othermaciej> | there's surface syntax errors where the motivation seems to be that they are likely to indicate an error, and may result in divergent behavior in older browsers |
| 05:55 | <othermaciej> | there's nesting rules where violating them results in parser madness (like <p> not allowed in <table>) or because some elements have very fixed behavior and other children don't make sense (like <div> not being allowed in <select>) |
| 05:55 | <MikeSmith> | othermaciej: right |
| 05:56 | <MikeSmith> | there are also cases like, you can't nest <a href>s if you want them to have an expected effect |
| 05:57 | <MikeSmith> | or, as a class, you can't nest interactive elements |
| 05:57 | <othermaciej> | there's nesting rules that are based on what is believed to be proper semantic structure, but which are not in any way enforced and won't cause interop problems if you violate them (like <b> not allowed immediately inside <ul>) |
| 05:58 | <othermaciej> | there's elements or attribute that have an effect but are banned because they are presentational |
| 05:58 | <MikeSmith> | yeah |
| 05:58 | <Hixie> | <b> inside <ul> will cause problems to any tool that tries to do anything useful with list items in a list |
| 05:58 | <othermaciej> | there's elements or attributes that have no effect, and may have been in older specs, but are banned because they are useless |
| 05:58 | <Hixie> | (e.g. scripts that resort lists) |
| 05:59 | <othermaciej> | there's elements or attributes that have no current effect and were never in a spec (the general ban on unknown elements or attributes) |
| 05:59 | <heycam> | Hixie, "but the novice authors is cautioned" in the new "A quick introduction to HTML" section |
| 05:59 | <othermaciej> | there's rules for attribute values that disallow things that can't have an effect because they don't satisfy the basic syntax of the attribute (that would be in the "likely to be an error" category) |
| 05:59 | <Hixie> | heycam: thanks |
| 06:00 | <othermaciej> | I'm not sure if that list of categories was exhaustive |
| 06:00 | <sayrer> | elements that have an effect but were never in a spec |
| 06:01 | <sayrer> | that's all I can think of |
| 06:02 | <othermaciej> | there's also mandatory content, like the fact that documents must have a <title> or that <img> elements must have a src attribute |
| 06:05 | <sayrer> | those last two seem different to me |
| 06:05 | <sayrer> | maybe it's not important |
| 06:06 | <othermaciej> | I see your point; not sure how to express the difference |
| 06:06 | <othermaciej> | some mandatory content is mandatory because the associated container won't work otherwise |
| 06:07 | <othermaciej> | many elements are also required to have " at least one descendant text node that is not inter-element whitespace, or at least one descendant element node that is embedded content" |
| 06:07 | <othermaciej> | which effectively rules out being empty |
| 06:08 | <othermaciej> | I'm not sure if that's in the "otherwise the element doesn't work" category of mandatory content, or the "because it seems right to require this" category |
| 06:08 | <sayrer> | one class of content nesting rules would seem to concern mark up where the DOM is quite different from the lexical nesting of the markup |
| 06:08 | <sayrer> | parser madness |
| 06:11 | <othermaciej> | if I'm reading the spec right, it seems like it is conforming for <table> or <ul> to be empty, but not for <p> or <b> to be empty |
| 06:12 | <sayrer> | interesting. people put empty <p> elements in to space things out quite a lot |
| 06:12 | <sayrer> | heretical |
| 06:13 | <othermaciej> | empty <p> elements collapse away |
| 06:14 | <othermaciej> | (at least by default; you could presumably style them not to) |
| 06:15 | <Hixie> | you must be reading an old version of the spec |
| 06:15 | <Hixie> | either that or i missed some bit |
| 06:15 | <Hixie> | because empty <p> is explicitly allowed (though mildly discouraged) to enable scripts to fill them in later |
| 06:15 | <Hixie> | and to allow templates to be filled in later yet still be validated |
| 06:17 | <sayrer> | oh right |
| 06:17 | <sayrer> | must be <br>s or something when they do that |
| 06:19 | <sayrer> | anyway, we have quite a few axes for these rules |
| 06:19 | <Hixie> | <br>s? |
| 06:19 | <othermaciej> | I see, "flow content" non-emptiness is a SHOULD now |
| 06:44 | <Hixie> | hsivonen: yt? |
| 06:44 | <Hixie> | hsivonen: i'm still baffled by http://www.w3.org/Bugs/Public/show_bug.cgi?id=6776 |
| 06:46 | <hsivonen> | Hixie: what's unclear? |
| 06:49 | <Hixie> | should i add something to the xhtml syntax section saying "XSLT 1.0 processors, when the method is 'html', must violate the XSLT 1.0 spec in the following way:"? |
| 06:49 | <Hixie> | or some other section? |
| 06:50 | <Hixie> | basically i don't understand where to put this |
| 06:50 | <hsivonen> | I'd put it near the text/html DOM API differences |
| 06:50 | <Hixie> | (and i am concerned about getting shot by the xslt working group for doing something that i really don't care about :-) ) |
| 06:50 | <Hixie> | the case sensitivity stuff? |
| 06:50 | <hsivonen> | it would be confusing to put this in XHTML section |
| 06:50 | <hsivonen> | yeah |
| 06:51 | <hsivonen> | for wg concerns, see the linked bug |
| 06:51 | <Hixie> | i don't see how the section you're indicating has anything to do with xslt whatsoever |
| 06:51 | <Hixie> | it's all about the DOM |
| 06:51 | <hsivonen> | this is about the DOM, too |
| 06:53 | <hsivonen> | XSLT processors that output to a character or byte stream are unaffected |
| 06:55 | <Hixie> | hmmm |
| 06:55 | <Hixie> | ok |
| 07:26 | <Hixie> | hsivonen: ok, how is http://www.whatwg.org/specs/web-apps/current-work/#dom-based-xslt-1.0-processors |
| 07:31 | <Hixie> | well i checked it in |
| 07:31 | <Hixie> | let me know how it is |
| 08:12 | <hsivonen> | Hixie: looks good |
| 08:12 | <Hixie> | woo |
| 08:13 | <hsivonen> | thanks |
| 09:26 | <Hixie> | hsivonen: still here? |
| 09:28 | <Hixie> | hsivonen: http://www.whatwg.org/specs/web-apps/current-work/#interactions-with-xpath-and-xslt |
| 09:28 | <Hixie> | checked in |
| 09:44 | <hsivonen> | Hixie: looks good. thanks |
| 09:45 | <hsivonen> | Hixie: can the XPath bit be annotated as implemented in Gecko and WebKit and the XSLT bit be annotated as implemented in Gecko? |
| 09:47 | <hsivonen> | hmm. does WebKit output to DOM from XSLT? |
| 09:48 | <othermaciej> | WebKit's XSLT will serialize and reparse |
| 09:48 | <hsivonen> | othermaciej: thanks |
| 09:49 | <Hixie> | hsivonen: reload and there should be separate IDs for the two parts of that section |
| 09:49 | <othermaciej> | I believe that makes the given conformance requirement inapplicable |
| 09:49 | <hsivonen> | othermaciej: it does, yes |
| 09:50 | <hsivonen> | I annotated Gecko and WebKit nightlies as supporting the section |
| 09:50 | <hsivonen> | since the last part doesn't apply to WebKit |
| 09:53 | <MikeSmith> | Hixie: can you conceive of any possible workaround for the Webkit bug that prevents get-author-view-onload of the spec from working? |
| 09:54 | <othermaciej> | MikeSmith: what's the bug? |
| 09:54 | <Hixie> | MikeSmith: i wrote a workaround earlier today |
| 09:55 | <Hixie> | othermaciej: .disabled doesn't seem to work on <link rel=stylesheet> in webkit the first time it's set, or something |
| 09:55 | <Hixie> | hsivonen: cool, thanks |
| 09:55 | <othermaciej> | weird |
| 09:56 | <Hixie> | othermaciej: i haven't created a minimal test case, so i don't know exactly what the issue is |
| 09:57 | <MikeSmith> | othermaciej: https://bugs.webkit.org/show_bug.cgi?id=26673 |
| 09:58 | <othermaciej> | sounds plausible |
| 09:58 | <othermaciej> | maybe a kind volunteer will make a reduction |
| 10:03 | <takkaria> | hey, has anyone got a recentish IE to hand? |
| 10:03 | <jgraham> | othermaciej: The thing that we are more likely to have to spend time on is how aria interacts with HTML semantically e.g. what does aria-labelledby mean on a table cell if it does/does not point to a table header |
| 10:03 | <jgraham> | takkaria: Install virtualbox :) |
| 10:03 | <jgraham> | (or: yes) |
| 10:04 | <takkaria> | I'm wondering what IE does if you go to "http://spaces.ru/fff/6789004718042409/0/427562/Gameloft_Asphalt_4_Elite_Racing_3D_HD_v1.0.6_S60v3_SymbianOS9.sisx";, mainly whether it tries to display the page or whether it pops up a download box |
| 10:04 | <othermaciej> | jgraham: I could also imagine additional validity rules preventing nonsensical combinations |
| 10:04 | <othermaciej> | like <input type="text" role="checkbox"> |
| 10:05 | <Hixie> | currently aria actually says we're not allowed to disallow that |
| 10:05 | <jgraham> | othermaciej: So can I |
| 10:05 | <Hixie> | that was one of my last call comments |
| 10:05 | <Hixie> | are there any content models that use "Text" other than <option>, <title>, and <textarea>? |
| 10:06 | <othermaciej> | Hixie: what's the specific part that says that? |
| 10:06 | <Hixie> | othermaciej: i forget the exact section off-hand |
| 10:07 | <othermaciej> | does it have conformance requirements for markup language specifications? |
| 10:08 | <othermaciej> | (they don't seem to have a clear statement of conformance classes) |
| 10:08 | <Hixie> | http://www.w3.org/WAI/PF/comments/details?comment_id=267 |
| 10:08 | <Hixie> | see section 6.1.1 |
| 10:09 | <Hixie> | http://www.w3.org/TR/2009/WD-wai-aria-20090224/#host_general_role |
| 10:09 | <othermaciej> | I see, that does seem like a problem |
| 10:10 | <othermaciej> | I wonder if that is intentionally meant to prevent banning of crazy combinations, or just an attempt to say a language can't ban all use of an ARIA role wholesale, without considering the issue |
| 10:12 | <jgraham> | othermaciej: I have heard various aria types insist that aria should always override host semantics so <input type=text role=checkbox> would be considered fine and indicative of a checkbox |
| 10:13 | <othermaciej> | jgraham: it's kind of crazy to consider it fine |
| 10:13 | <othermaciej> | but one thing I didn't realize before is that overriding host semantics has some associated implementation challenge |
| 10:14 | <othermaciej> | because any time an ARIA-related attribute is set at all, you have to stop doing all or most of the built-in accessibility behavior |
| 10:14 | <Philip`> | takkaria: I get a download prompt in IE8 on Vista |
| 10:14 | <othermaciej> | or at least, it seems like the output of assistive technologies would be nonsense if something was both a checkbox and a text box, or (as in Hixie's example) both checked and unchecked |
| 10:16 | <takkaria> | Philip`: thanks |
| 10:25 | <Hixie> | i just got my first ironic error message from hsivonen's validator |
| 10:26 | <jgraham> | The validator does irony now? |
| 10:27 | <Hixie> | while validating the spec after changing it to allow <p> in <caption>, which included a change to an example to add an actual <p> to an actual <caption>, the validator told me that that was wrong. |
| 10:27 | <takkaria> | you need a "I am the spec author and what I say goes" box on v.nu |
| 10:29 | <Hixie> | actually adding the validator step to my generator script has caught so many typos and errors that it's awesome |
| 10:41 | <MikeSmith> | jgraham, Hixie: browsers generally behave as expected for multiple pargraphs or lists in a <caption>? |
| 10:43 | <jgraham> | MikeSmith: AFAICT yes |
| 10:45 | <hsivonen> | how many WebKit ports does Nokia have and how many of them are active? |
| 10:45 | <MikeSmith> | hsivonen: as far as I know of it least, they have one: the native S60 port |
| 10:46 | <othermaciej> | they have the Qt port |
| 10:46 | <MikeSmith> | and it is not being actively developed, and has not been for a long time |
| 10:46 | <othermaciej> | as far as I know, that's the only port that Nokia actually maintains upstream |
| 10:46 | <MikeSmith> | othermaciej: they have an S60 QtWebKit port now |
| 10:47 | <othermaciej> | I don't know what if anything they do in private trees |
| 10:47 | <MikeSmith> | a "pre-release" one - http://sideshowbarker.net/2009/06/26/s60-qtwebkit/ |
| 10:48 | <hsivonen> | MikeSmith: the native S60 port that shipped with S60r3.1 is dead, right? so is QtWebKit what they are on track shipping when they next refresh the bundled browser on S60? |
| 10:48 | <MikeSmith> | hsivonen: as far as I can tell, yeah, the native S60 port is dead. |
| 10:48 | <hsivonen> | ok |
| 10:49 | <MikeSmith> | as far as how QtWebKit fits into their product plans, they have said nothing publicly |
| 10:49 | <othermaciej> | they don't maintain the webkit.org copy of it that lives on a very old branch |
| 10:49 | <othermaciej> | (the native S60 port) |
| 10:50 | <MikeSmith> | http://sideshowbarker.net/2008/04/11/s60-webkit-dead/ |
| 10:52 | <MikeSmith> | that was more than 1 year ago, they closed all open bugs on it en masse |
| 10:52 | <MikeSmith> | after there had at that time not been any checkins to the branch for 8 months |
| 10:52 | <othermaciej> | I would guess the native S60 port is abandoned but there's not been a definitive statement |
| 10:52 | <othermaciej> | it's possible they did all sorts of things in a private tree, or maybe not |
| 10:53 | <othermaciej> | who knows? |
| 10:54 | <MikeSmith> | the work QtWebKit port for S60 is being done in public, I think |
| 10:54 | <MikeSmith> | I mean, I think they have a publicly readable repository |
| 10:54 | <MikeSmith> | heh |
| 10:54 | <MikeSmith> | this is what dude wrote at the time in response to my post - |
| 10:54 | <MikeSmith> | http://blogs.s60.com/2008/04/whoa_there |
| 10:55 | <othermaciej> | sure, it's clear that QtWebKit for S60 is being worked on |
| 10:55 | <othermaciej> | and one could certainly guess they want this to be part of their product strategy |
| 10:55 | <MikeSmith> | "We are not backing away from Webkit no matter what you might have read on one of those new-fangled “website” things ... No, no, no — it’s just that we’re focusing on the newer Leopard branch" |
| 10:56 | <MikeSmith> | anyway, ancient history now |
| 10:56 | <othermaciej> | I believe they tried to bring their port up to the Safari 3.0 version of WebKit and failed |
| 10:58 | <Hixie> | ok time to go to bed |
| 10:58 | <Hixie> | actually long past time to go to bed |
| 10:58 | <Hixie> | nn |
| 11:16 | <Romme> | is here a right place to ask about html5lib? i've googled, but still haven't found the answer |
| 11:17 | <takkaria> | sure |
| 11:20 | <jgraham> | Romme: Ask away |
| 11:21 | <hsivonen> | Nokia also has a port of WebKit for Maemo, right? A variant of the GTK port. |
| 11:21 | <Romme> | jgraham: how do i serialize an element without including it's start and end tags? |
| 11:24 | <Romme> | i've tried ''.join(serializer.HTMLSerializer().serialize(walker(lxmletree.FragmentRoot(content)), 'UTF-8')), where content is my element |
| 11:25 | <Romme> | but it then serializes everything until my document ends |
| 11:28 | <Romme> | and i don't quite understand what FragmentWrapper and FragmentRoot are for |
| 11:31 | <jgraham> | Romme: Of the top of my head I don't think we support that in an easy way but it does seen like a reasonable feature request. I'm pretty sure it is possible to hack |
| 11:31 | <jgraham> | (sorry I got distracted by rl) |
| 11:32 | <Romme> | i've heard that if i parse my data with parseFragment, then i will get a fragment when serializing as well, but the problem is, i'm not parsing a fragment, but a document instead |
| 11:34 | <jgraham> | Romme: Which tree backend are you using? |
| 11:34 | <Romme> | jgraham: lxml |
| 11:36 | <takkaria> | are there any tests for abarth's content-type sniffing draft? |
| 11:36 | <jgraham> | Romme: Give me a moment I will just check something |
| 11:36 | <jgraham> | takkaria: IIRC gsnedders has some |
| 11:37 | <takkaria> | hm, I guess I'll wait til he comes online again |
| 11:38 | <jgraham> | takkaria: You may see him in person before then :) |
| 11:39 | <takkaria> | that is a point :) |
| 11:41 | <jgraham> | Romme: t = html5lib.parse("<div><a>b</a> abc <b>c</b></div>", treebuilder="lxml") |
| 11:41 | <jgraham> | tw = html5lib.treewalkers.getTreeWalker("lxml") |
| 11:41 | <jgraham> | div = t.find("//div") |
| 11:41 | <jgraham> | for item in tw(list(div)):print item |
| 11:42 | <jgraham> | gives all the children of the <div> but not the <div> itself. So I guess that will serialize OK |
| 11:42 | <Romme> | i would have just serialized it with lxml then :P |
| 11:43 | <Romme> | i need the features of html5lib, like omitting optional tags or quotes in attribute names |
| 11:43 | <Romme> | oops |
| 11:43 | <Romme> | sorry |
| 11:44 | <Romme> | didn't notice the "tw" |
| 11:44 | <jgraham> | s = html5lib.serializer.HTMLSerializer() |
| 11:44 | <jgraham> | s.render(tw(list(div))) |
| 11:44 | <jgraham> | u'<a>b</a> abc <b>c</b>' |
| 11:46 | <Romme> | i wonder why render() converts it to a list instead of just iterating |
| 11:48 | <Romme> | jgraham: thanks, but that serialized it until my document ended |
| 11:49 | <jgraham> | Romme: I don't actually know, but it might be a theory that doing join on a list is faster than joing it on an iterator. I have no idea if this is true or not |
| 11:49 | <Romme> | with end tags for element which haven't started |
| 11:49 | <jgraham> | Romme: Can you give an example of something that doesn't work? |
| 11:50 | <Romme> | jgraham: wait a moment, i'll create a testcase |
| 11:52 | jgraham | notes that using list() or not seems to make no speed difference |
| 11:55 | <Romme> | a few more minutes |
| 12:05 | <Romme> | jgraham: http://files.getdropbox.com/u/268483/testcase.tar.bz2 |
| 12:15 | <Midler1> | In case someone of you have missed (its not about html5...but still) http://blogs.msdn.com/outlook/archive/2009/06/24/the-power-of-word-in-outlook.aspx#commentform |
| 12:16 | <Midler1> | its like they will stay in the 90:s forever |
| 12:24 | <Romme> | well, at least they're not dicks about letting us hide that thing out of sight. i'm quite tired of minimizing evolution and moving it to the second workspace |
| 12:26 | <jgraham> | Romme: AFAICT your testcase works. At least the textcontent of the serialized fragment seems to be the same as that of the div element |
| 12:27 | <jgraham> | Possibly the div just doesn't get closed? |
| 12:28 | <Romme> | jgraham: Vim confirms that the div is indeed closed |
| 12:28 | <Romme> | hmmph, maybe it's just my version of html5lib, i'll try installing the newest one |
| 12:28 | <Romme> | what version are you using? |
| 12:29 | <jgraham> | Romme: Some random development version. I don't recommend pulling the head at the moment though; things are not really in a perfect state |
| 12:29 | <jgraham> | This is unlikely to have changed |
| 12:34 | <jgraham> | Oh wait, I am probably wrong |
| 12:58 | <jgraham> | Romme: When I said I was wrong, I meant about the testcase working for me. I was comparing the wrong things. I think the solution is more complex than I first thought |
| 12:58 | <jgraham> | One approach would be to write a filter that dropped the first tag and everything after the matching end tag |
| 13:01 | <jgraham> | In theory using copy.deepcopy to get the nodes into a list could work (because afaik it breaks parent pointers) but I think it doesn't actually work right now |
| 13:01 | <jgraham> | File a feature request |
| 13:04 | Philip` | decides that writing a GUI half in C++ and half in JS is actually quite a pain |
| 13:04 | <Philip`> | so I suppose I should just rewrite it all in JS |
| 13:04 | <hsivonen> | Philip`: Firefox? |
| 13:05 | <Philip`> | hsivonen: No, something using wxWidgets |
| 13:10 | <Philip`> | Hmm, I currently have three separate sections of code viewing and controlling the same piece of data (GUI written in JS; GUI written in C++; game engine in C++ in another thread) - I wonder if there's meant to be some magic design pattern that makes it all stay in sync trivially... |
| 13:12 | <Philip`> | s/makes/would make/ |
| 13:22 | <hendry> | Philip`: when in doubt, write in C |
| 13:50 | <Philip`> | hendry: I'd generally prefer to make things easier for myself, not harder :-) |
| 23:07 | gsnedders | waves |
| 23:08 | <gsnedders> | (From Sweden) |
| 23:13 | <Midler> | lol |
| 23:13 | <Midler> | comhem.. |
| 23:13 | <Midler> | gsnedders: I can see that |