| 00:04 | <Philip`> | http://lachy.id.au/log/2005/05/script-comments says "the only user agent I know of the supports the CDATA section for HTML documents is the new Opera 8", so it sounds like it wasn't added before v8. (I have no idea why they ever added it, particularly with such an intriguing implementation...) |
| 00:04 | <Hixie> | yeah |
| 00:04 | <Hixie> | well |
| 00:04 | <Hixie> | no comment |
| 00:05 | <Hixie> | i love how zcorpan reported the same issue several times (probably without realising it) |
| 01:00 | <Hixie> | ok i'm sure what i just did just about broke everything in the spec |
| 01:00 | <Hixie> | so, please let me know if you find issues with those checkins... |
| 01:03 | <jruderman> | Hixie: did you just set the spec on fire? |
| 01:04 | <Hixie> | i abstracted out innerHTML's getter and setter to generic algorithms |
| 01:12 | <Philip`> | Looks like the innerHTML link in item 3 a bit below http://www.whatwg.org/specs/web-apps/current-work/#innerhtml1 should link to innerhtml1 (to be consistent with all the others in that section) instead of innerhtml0. Or maybe all those should link to innerhtml0 instead, or something. |
| 01:13 | <Hixie> | oops |
| 01:14 | <Hixie> | will dix |
| 01:14 | <Hixie> | f6ix |
| 01:14 | <Hixie> | fix |
| 01:33 | <Philip`> | Ooh, excellent, I get non-deterministic behaviour when drawing a couple of arcs and rectangles in Opera |
| 01:35 | <Hixie> | uri? |
| 01:36 | <Philip`> | Just trying to make a sensible test case now |
| 01:42 | Hixie | giggles |
| 01:42 | <Hixie> | one of my colleagues introduced me to one of our interns, saying i was a standards guru |
| 01:42 | <Hixie> | the intern asked if i knew about the whatwg |
| 01:43 | <bewest> | hehe |
| 01:43 | <bewest> | do you pronounce whatwg? |
| 01:43 | <bewest> | or do you say W-H-A.... |
| 01:44 | <Hixie> | i pronounce it "whatwuhjee" |
| 01:44 | <Hixie> | and i guess that's canonical since i came up with it |
| 01:44 | <Hixie> | when i'm talking more formally i call it the "What double you gee" |
| 01:45 | <Philip`> | http://canvex.lazyilluminati.com/misc/operanondet.html - that's running the same code lots of times, and I get a random selection of about four renderings (of which two are quite rare) |
| 01:45 | <bewest> | I usually say whatwahguhdfm..... |
| 01:45 | <Philip`> | ...in Opera 9.21 on Windows and Linux |
| 01:45 | <Philip`> | (Turns out it doesn't actually need arcs at all) |
| 01:46 | <Hixie> | all look the same to me on 9.00 |
| 01:46 | <Hixie> | (windows) |
| 01:46 | <Hixie> | bewest: whatwahguhdfm? |
| 01:46 | <Philip`> | Does it stay the same if you reload the page a few times? |
| 01:46 | <Hixie> | (wish it was easier to keep up to date with opera, sheesh) |
| 01:46 | <Hixie> | seems yes |
| 01:47 | <bewest> | Hixie: yes, and then my voice kind of trails off at the end, and then I resume what I was saying. |
| 01:47 | <Hixie> | heh |
| 01:48 | <Hixie> | i recommend "whatwuhjee" |
| 01:48 | <bewest> | yeah, seems better. |
| 01:48 | <Hixie> | Philip`: wow, yeah, opera 9.21 is all over the place |
| 01:51 | <Philip`> | http://canvex.lazyilluminati.com/misc/operanondet.png - that has all the four renderings I've noticed |
| 01:59 | <Hixie> | funky |
| 02:01 | <Hixie> | ok, renamed "innerHTML case" to "fragment case" |
| 02:02 | <Hixie> | wow, the last csswg meeting had all of four people on the call |
| 02:35 | <Hixie> | http://bugs.webkit.org/show_bug.cgi?id=12740 is heartwarming |
| 02:35 | <othermaciej> | like heartburn? |
| 02:36 | <Hixie> | no |
| 02:36 | <Hixie> | like a hug :-P |
| 02:37 | <othermaciej> | ah yes, that was a nice fix |
| 02:37 | <othermaciej> | interop problem solved by following spec |
| 02:40 | <karlUshi> | othermaciej: which part of the spec? |
| 02:40 | <othermaciej> | Hixie: part of the HTML5 parsing algorithm |
| 02:40 | <Hixie> | i assume that was to karl |
| 02:40 | <karlUshi> | ;) |
| 02:40 | <Hixie> | since i looked at the bug and therefore knew :-) |
| 02:41 | <othermaciej> | er, yeah |
| 02:41 | <othermaciej> | karlUshi: meant that for you |
| 02:41 | <karlUshi> | a specific part of the parsing algorithm |
| 02:42 | <karlUshi> | I have an idea to explain people why html5 parsing rules are important. |
| 02:42 | <karlUshi> | I think it is a good example |
| 02:45 | <karlUshi> | http://dev.w3.org/cvsweb/~checkout~/html5/spec/Overview.html#in-table |
| 02:46 | <karlUshi> | it seems to be it |
| 02:51 | <Philip`> | karlUshi: Looks like the "A start tag whose tag name is "table"" case in there, in particular |
| 03:30 | <Lachy> | Hixie, yt? |
| 03:51 | <Hixie> | yo |
| 03:52 | <Hixie> | Lachy? |
| 03:56 | <Lachy> | hey |
| 03:56 | <Lachy> | regarding Selectors API, Jonas' last message on member-webapi and http://lists.w3.org/Archives/Public/public-webapi/2006Sep/0100.html |
| 03:57 | <Lachy> | I'm wondering if you could help me understand what the issue is - there doesn't seem to be one |
| 03:57 | <Hixie> | which part? |
| 03:57 | <Lachy> | in particular, the scoped selectors part. |
| 03:58 | <Lachy> | AFAIK, scoped selectors don't exist, so how can I deal with them? |
| 03:58 | <Hixie> | i don't see the problem either |
| 04:00 | <Lachy> | also, regarding the :root issue, it seems to me that it would only ever match the root of the document, not the root of a subtree, so I don't see what the problem is there either |
| 04:00 | <Hixie> | i agree |
| 04:00 | Hixie | wonders exactly what chaals meant in reply to the f2f questionnaire |
| 04:00 | <Lachy> | cool. I'll just reply and explain why it's not an issue. |
| 04:01 | <Hixie> | i can't tell if he thinks i'm wrong in saying the telecon was a waste of time or what |
| 04:01 | <Hixie> | guess i'll have to catch him online at some point |
| 04:01 | <Lachy> | which f2f questionaire? |
| 04:01 | <Hixie> | http://www.w3.org/2002/09/wbs/40318/mtgmv/ |
| 04:02 | <Hixie> | given that only 13 people replied, and at least one of them only replied because i asked them about it, i'm starting to wonder if anyone actually reads public-html these days |
| 04:02 | <Lachy> | I haven't paid much attention to it recently. I marked about ~300 messages as read a few days ago cause I couldn't be bothered |
| 04:03 | <Lachy> | I didn't even know they were going to have an f2f |
| 04:03 | <Hixie> | heh |
| 04:05 | <Hixie> | right, going home |
| 04:05 | <Hixie> | bbl |
| 04:05 | <Lachy> | ok, cya |
| 04:08 | <Philip`> | Hmm, commit-watchers seems to still be randomly ignoring some commits (823, 839, 898, 908, 912, 932, 934) |
| 06:47 | <Hixie> | Philip`: weird |
| 06:51 | <Lachy_> | what do people think of selectOne/selectAll as the resolution to the selectors api naming debate? (I'm currently going through ~300 emails reviewing the arguments) |
| 06:59 | <Hixie> | sounds good to me, but i think the reason anne didn't pick those is that they are either too similar or actually clash with the xpath functions that IE supports |
| 07:00 | <Lachy_> | yeah, I did the research on that. XPath uses selectSingleNode/selectNodes |
| 07:00 | <Lachy_> | .select() is out because it's already used in <textarea> and <input type=text> APIs |
| 07:01 | <Lachy_> | the other alternative I'm considering is choose*() |
| 07:02 | <Hixie> | i prefer select |
| 07:02 | <Lachy_> | me too |
| 07:02 | Hixie | finds a page that renders differently in IE than in other browsers because <span> is not considered a formatting element |
| 07:02 | <Lachy_> | I still have about 150 emails to get through. Then I'll finish summarising the arguments and send the results to the list |
| 07:06 | <Hixie> | and then you'll be told you're being biased, and will have to ignore about 30% of the people, who will raise formal objections... welcome to the editor's job :-) |
| 07:07 | <Lachy_> | yeah, why do you think I've been avoiding the issue for so long? :-) |
| 07:07 | <Lachy_> | at least the CSS WG resolved the case sesitivity issue for me earlier today :-) |
| 07:11 | <Hixie> | yeah |
| 07:11 | <Hixie> | impressive |
| 07:12 | <Lachy_> | are you going to consider fixing the issue in XBL to make the prefixes case senstive now, or just leave it as is? |
| 07:12 | <Hixie> | i'll fix it in due course |
| 07:12 | <Lachy_> | cool |
| 07:19 | <Hixie> | annevk: yt? |
| 07:36 | <Hixie> | http://news.com.com/8301-10784_3-9731230-7.html?part=rss&subj=news&tag=2547-1_3-0-5 |
| 07:36 | <Hixie> | seriously, they're getting worse |
| 07:36 | <Hixie> | when will they learn? |
| 07:36 | <Lachy_> | yeah, I noticed that earlier. I just laughed |
| 07:48 | <Lachy_> | oh dear! Flash CS3 apparently uses document.selectAll() already :-( |
| 07:48 | <karlUshi> | Hixie: you mean journalists… indeed :p Tempest in a tea post |
| 07:49 | <karlUshi> | slashdot is more interesting on the issue |
| 07:49 | <othermaciej> | Lachy_: for what? |
| 07:49 | <othermaciej> | what does it expect selectAll to do? |
| 07:50 | <Lachy_> | I'm getting the link... |
| 07:50 | <Lachy_> | http://livedocs.adobe.com/flash/9.0/main/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Parts&file=00003989.html |
| 07:51 | <Lachy_> | it apparently seems to do text selection, though I'm not totally sure |
| 07:51 | <othermaciej> | so wait, Flash extends the Document object? |
| 07:51 | othermaciej | is confused |
| 07:52 | <othermaciej> | "The Document object represents the Stage. That is, only FLA files are considered documents." |
| 07:52 | <Lachy_> | well, it calls it a DOM, but it doesn't seem to be related to the W3C DOM |
| 07:52 | <othermaciej> | none of that stuff is in any way related to the DOM as we know it, as far as I can tell |
| 07:53 | <othermaciej> | Lachy_: the article about the w3c is hilarious |
| 07:55 | <zcorpan_> | can anyone access http://forums.whatwg.org/ ? |
| 07:55 | <Lachy_> | zcorpan_, no |
| 08:02 | <zcorpan_> | ok |
| 08:03 | <Hixie> | server is rebooting |
| 08:03 | <MikeSmith> | great to see that Declan McCullagh at it again |
| 08:35 | <zcorpan_> | does it matter whether something is implemented in the tokenizer or the parser? |
| 08:37 | <hsivonen> | zcorpan_: if you want to use tokenizer-specific unit tests, yes. |
| 08:37 | <hsivonen> | zcorpan_: matter for whom? |
| 08:38 | <hsivonen> | zcorpan_: also, in the case of Java (or C#, I presume), upper or lower casing stuff in the tokenizer is a bit cheaper than leaving it to the tree builder |
| 08:39 | <hsivonen> | (languages that have both char[] and immutable String) |
| 08:39 | <hsivonen> | scratch that--the statement makes assumptions about the interface between the tokenizer and the tree builder |
| 08:41 | <zcorpan_> | hsivonen: whether it matters for spec conformance |
| 08:42 | <hsivonen> | zcorpan_: it may matter to the order of parse errors |
| 08:42 | <hsivonen> | zcorpan_: I'd expect |
| 08:42 | <othermaciej> | does the spec require a particular order for parse errors? |
| 08:43 | <hsivonen> | othermaciej: IIRC, there was some language tied to "first" |
| 08:43 | <zcorpan_> | e.g., if something is more performant to implement in the parser for implementor A and more performant to implement in the tokenizer for implementor B, and the end result is the same, then i don't see a good reason to make one implementation non-conforming |
| 08:44 | <hsivonen> | zcorpan_: agreed |
| 08:45 | <hsivonen> | othermaciej: ah. not relevant. it was not the first as defined by the algorithm but the first for which the impl takes special action |
| 08:46 | <hsivonen> | "The error handling for parse errors is well-defined: user agents must either act as described below when encountering such problems, or must abort processing at the first error that they encounter for which they do not wish to apply the rules described below." |
| 08:47 | <zcorpan_> | could be phrased as s/the first/any/ |
| 08:49 | <hsivonen> | fwiw, I'll probably make following that rule optional |
| 08:49 | <hsivonen> | (i.e. allow the user of the parser to enable non-conforming coercion to XML 1.0 infoset) |
| 08:50 | <hsivonen> | in the parser library that is--not in the conformance checker |
| 09:13 | <hsivonen> | hmm. the state transitions between the new comment states aren't nice |
| 09:13 | hsivonen | wonders if one state with hyphen counting would work |
| 09:15 | <zcorpan_> | hmm, writing test cases for .lastModified seems non-trivial |
| 09:15 | <zcorpan_> | or not, i can use http headers |
| 09:18 | <hsivonen> | it seems to me that it is the easiest to combine the last three comment states and to use a counter |
| 09:21 | <zcorpan_> | "The last two digits of the year component of the date." -- shouldn't this be 4 digits? |
| 09:26 | <Hixie> | hsivonen: the biggest problem with that is getting the parse errors right |
| 09:27 | <hsivonen> | Hixie: "that" being a counter? |
| 09:27 | <Hixie> | yeah |
| 09:27 | <Hixie> | well, with not using the numerous states i used |
| 09:28 | <zcorpan_> | Hixie: was the year component of .lastModified a mistake? should i bug the list about it? (all browsers return the year in 4 digits) |
| 09:28 | <Hixie> | why are the states troublesome? because of using a stack-based approach instead of a switch? or? |
| 09:29 | <hsivonen> | Hixie: using a stack-based approach and I don't want arbitrary recursion based on input |
| 09:29 | <Hixie> | zcorpan_: hm |
| 09:29 | <hsivonen> | Hixie: plus the direct transition to comment end state from comment start dash state |
| 09:30 | <Hixie> | ah |
| 09:30 | <Hixie> | just have a little state machine in your function :-) |
| 09:30 | <hsivonen> | Hixie: isn't the counter exactly it? |
| 09:31 | <hsivonen> | 0: comment 1: end dash 2: end |
| 09:31 | <Hixie> | well, if you get the parse errors right |
| 09:31 | <Hixie> | <!--> has a parse error, <!----> does not |
| 09:31 | <Hixie> | <!---> has a parse error, <!-- ---> has a parse error |
| 09:32 | <Hixie> | <!-- --> does not |
| 09:33 | <Hixie> | zcorpan_: oops, i'll fix that |
| 09:33 | <Hixie> | zcorpan_: no need to report it |
| 09:33 | <hsivonen> | Hixie: um. according to the revision of comment start dash state that I am looking at, <!--> does not have a parse error |
| 09:33 | <zcorpan_> | Hixie: ok |
| 09:33 | <hsivonen> | oop |
| 09:33 | <hsivonen> | s |
| 09:34 | <hsivonen> | never mind |
| 09:34 | <Hixie> | you start in the comment start state, not the comment start dash state |
| 09:34 | <hsivonen> | Hixie: I wasn't going to use a counter for the comment start * states |
| 09:35 | <Hixie> | ah ok |
| 09:43 | <annevk> | Hixie, I am here now |
| 09:43 | <Hixie> | sent you mail |
| 09:43 | <annevk> | having said that, I haven't checked e-mail so far |
| 09:43 | <annevk> | ok |
| 09:43 | <hsivonen> | Hixie: considering markup decl open state, how could you ever go through the comment start* states without hitting the '-' cases? |
| 09:44 | <hsivonen> | "If the next two characters are both U+002D HYPHEN-MINUS (-) characters, consume those two characters, create a comment token whose data is the empty string, and switch to the comment start state." |
| 09:44 | <Hixie> | they're consumed (by the text you just quoted) before you enter that state |
| 09:46 | <hsivonen> | ooh! the purpose of those states is very different from what I though |
| 09:46 | <hsivonen> | t |
| 09:47 | <Hixie> | oh |
| 09:47 | <Hixie> | heh :-) |
| 09:47 | <hsivonen> | calling them "start" is confusing |
| 09:48 | <Hixie> | why? |
| 09:48 | <Hixie> | they're at the start |
| 09:48 | <hsivonen> | when they actually test for bogus end |
| 09:48 | <Hixie> | what should i call them? |
| 09:48 | <Hixie> | i don't want to have the tokeniser enter a state with the name "bogus" for quite compliant markup |
| 09:48 | <hsivonen> | commentPotentiallyBogusDashOne commentPotentiallyBogusDashTwo |
| 09:50 | <annevk> | whoa |
| 09:50 | <Hixie> | i don't like names with "bogus" in them that are not bogus :-) |
| 09:50 | <Hixie> | "whoa"? |
| 09:51 | <hsivonen> | Hixie: only *potentially# |
| 09:51 | <Hixie> | oh i understand your proposal |
| 09:51 | <Hixie> | i just don't particularly like it :-) |
| 09:51 | <Hixie> | i understand how the current text is confusing though |
| 09:52 | <hsivonen> | annevk: what was your reading of the purpose of the new states? |
| 09:52 | <annevk> | whoa was in response to the new names |
| 09:52 | <annevk> | hsivonen, to address parse errors for <!--> and <!---> |
| 09:53 | <hsivonen> | annevk: yeah, but was your intuitive reading that <!--> would go through comment start dash? |
| 09:53 | <hsivonen> | annevk: am I the only one who is confused? |
| 09:53 | <Hixie> | i agree that the current state names are confusing |
| 09:53 | <Hixie> | and will look for better names |
| 09:53 | <hsivonen> | Hixie: ok thanks |
| 09:54 | <Hixie> | on another note, the w3c pubrules checker is retarded |
| 09:55 | <annevk> | hsivonen, how does <!--> go through comment start dash? it is emitted during comment start |
| 10:04 | <hsivonen> | annevk: it doesn't. that's my point |
| 10:05 | <zcorpan_> | Hixie: wow this is interesting. ie takes daylight-saving time into account for .lastModified. firefox doesn't. |
| 10:06 | <annevk> | hmm |
| 10:06 | <annevk> | I suppose I'm too used to everything after <!-- being the start of the comment |
| 10:06 | <zcorpan_> | http://simon.html5.org/test/html/dom/interfaces/HTMLDocument/lastModified/001.php |
| 10:07 | <zcorpan_> | in ie, it failed, but when i turned off "automatically adjust daylight-saving time" in windows, the test passed |
| 10:07 | <hsivonen> | on a related note: if an HTML5 doc contains <!--a--b-->, what would you like the result of XHTML5 conversion be? (assuming fatal error is not an option) |
| 10:07 | <zcorpan_> | in firefox it passed both times |
| 10:09 | <hsivonen> | is substituting two EN DASHes in the middle evil and/or confusing? what about a single U+FFFD? |
| 10:11 | <annevk> | I think the DOM spec suggested something like "--" -> "- -" |
| 10:11 | <hsivonen> | ok |
| 10:14 | <annevk> | Hixie, does Google have some secret project that relies on the placement of comments? :) |
| 10:14 | <zcorpan_> | "The presence of this character sequence must generate a fatal error during serialization." -- http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-1728279322 |
| 10:15 | <annevk> | I stick with my suggestion |
| 10:15 | <annevk> | I believe browsers already support <base> in XHTML |
| 10:16 | <hsivonen> | zcorpan_: let's assume I'm going to have an infoset-altering option for everything that the specs say is fatal |
| 10:17 | <zcorpan_> | hsivonen: ok. that was the text i found when looking for what annevk referred to ("--" -> "- -") |
| 10:17 | <zcorpan_> | (that almost looked like a smiley) |
| 10:19 | zcorpan_ | will bug the list about daylight-saving time on .lastModified |
| 10:19 | <hsivonen> | the whattf CVS to SVN migration support thread has 14 messages and the transition still isn't done... |
| 10:19 | <hsivonen> | not counting my replies |
| 10:21 | <Hixie> | annevk: heh, no, i just want whitespace and comments to be in the DOM in the same place they are in the markup |
| 10:22 | <hsivonen> | Hixie: that'll be another use of XmlViolationPolicy.ALTER_INFOSET, then |
| 10:23 | <Hixie> | which? |
| 10:23 | <hsivonen> | Hixie: appending stuff to </head> |
| 10:23 | <hsivonen> | to head |
| 10:23 | <hsivonen> | after </head> has been seen |
| 10:24 | <hsivonen> | or are there those cases still |
| 10:24 | <hsivonen> | perhaps I'm just way too confused this morning. I woke up too early |
| 10:25 | <Hixie> | heh |
| 10:26 | <zcorpan_> | is it possible to get daylight-saving time info from javascript? |
| 10:26 | <hsivonen> | annevk: is your remainin </head> suggestion only about white space and comments? |
| 10:29 | <zcorpan_> | iirc, firefox inserts whitespace and comments that appear before <head> in the HEAD, and after </body> in the BODY. and between </head> and <body> in HEAD. |
| 10:31 | <annevk> | If we ignore </head> there's no moving around of elements anymore |
| 10:31 | <annevk> | a lot less special processing |
| 10:31 | <annevk> | and in general a simpler parsing model |
| 10:32 | <Hixie> | the complexity involved here is miniscule compared to almost any other part of the spec |
| 10:35 | <zcorpan_> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21--before-doctype--%3E%3C%21doctype%20html%3E%3C%21--before-html--%3E%3Chtml%3E%3C%21--before-head--%3E%3Chead%3E%3C/head%3E%3C%21--before-body--%3E%3Cbody%3E%3C/body%3E%3C%21--after-body--%3E%3C/html%3E%3C%21--after-html--%3E |
| 10:36 | <annevk> | after body and after html will always be part of body I believe |
| 10:36 | <Hixie> | not in html5 |
| 10:37 | <Hixie> | i need to find a way to handle whitespace, too |
| 10:37 | <Hixie> | i can reuse whatever solution i find for <table> whitespace processing |
| 10:39 | <hsivonen> | there are way too many pointless edge case differences between html4, html5 and xml 1.0 |
| 10:39 | <hsivonen> | I don't care about xml 1.1, which is itself pointless |
| 10:40 | <hsivonen> | unfortunately, the silliness is mostly due to XML banning arbitrary stuff |
| 10:40 | <annevk> | or html5 allowing arbitrary stuff |
| 10:41 | <hsivonen> | well, yeah |
| 10:41 | <annevk> | then again, html was there first |
| 10:41 | <zcorpan_> | the arbitrary stuff in xml was copied from sgml, wasn't it? |
| 10:42 | <hsivonen> | zcorpan_: U+FFFE and U+FFFF sure were not |
| 10:43 | <zcorpan_> | hsivonen: ok. |
| 10:43 | hsivonen | wonders who is actually able to use U+FFFF as a sentinel |
| 10:46 | <Lachy_> | wow! I just finished reading through every email I have on the naming debate :-) |
| 10:46 | <hsivonen> | Lachy_: naming? |
| 10:46 | <Lachy_> | selectors api |
| 10:46 | <hsivonen> | Lachy_: onwards to XHTML5 then :-) |
| 10:46 | <Lachy_> | the debate between matchAll()/getElementBySelector() and dozens of other alternatives |
| 10:47 | <zcorpan_> | Lachy_: did you get any wiser? :) |
| 10:47 | <Lachy_> | I'm about to send the summary of my research to public-webapi |
| 10:48 | <Lachy_> | sadly, I had to give up on selectOne/selectAll idea :-( |
| 10:48 | <Lachy_> | I'm considering a few like the following... |
| 10:48 | <Lachy_> | selectElement/selectElementList |
| 10:48 | <Lachy_> | getElement/getElementList |
| 10:49 | <othermaciej> | selectElement would be extremely confusing given selectSingleNode |
| 10:49 | <othermaciej> | I would sugget cssQuery / cssQueryAll or cssQueryOne / cssQuery |
| 10:49 | <zcorpan_> | Lachy_: was it pointed out that dean edwards' base2 uses matchAll() and matchSingle() to implement the spec? |
| 10:49 | <othermaciej> | short and unambiguous |
| 10:49 | <Lachy_> | yeah, that's the argument against all the select* alternatives |
| 10:49 | <Lachy_> | zcorpan_, yes, I'm aware |
| 10:50 | <Hixie> | nn all |
| 10:50 | <Lachy_> | cya hixie |
| 10:50 | <zcorpan_> | Hixie: nn |
| 10:50 | <hsivonen> | nn |
| 10:51 | <othermaciej> | I'm not a fan of the getElementBySelector name that was theoretically chosen by the group but never put in the spec |
| 10:51 | <othermaciej> | but I also think on further thought that get() / getAll() is a little *too* concise |
| 10:51 | <annevk> | the problem with that is chosing a name for the one that matches multiple |
| 10:52 | <Lachy_> | if we didn't need to have both methods, I'd just go for getElementsBySelector() |
| 10:52 | <othermaciej> | I hate how long it is |
| 10:52 | <annevk> | yeah, me too |
| 10:52 | <Lachy_> | I know, me too |
| 10:52 | <othermaciej> | cssQuery |
| 10:52 | <othermaciej> | short, unambiguous |
| 10:52 | <annevk> | matchAll and matchSingle is already implemented :) |
| 10:52 | <Lachy_> | I'm not a fan of having css in the name |
| 10:53 | <othermaciej> | css is inaccurate |
| 10:53 | <annevk> | are, even |
| 10:53 | <othermaciej> | but is also a very common name for the similar function in JS libraries |
| 10:53 | <Lachy_> | yeah, that's a good argument in favour of the match* methods |
| 10:53 | <othermaciej> | people call it a "css query api" |
| 10:53 | <annevk> | terrible |
| 10:54 | <othermaciej> | microsoft's implementation comments were weird |
| 11:01 | Lachy_ | mailed public-webapi with the list of alternatives and the summary of the arguments |
| 11:06 | <annevk> | getElementByGroupOfSelectors() and getElementsByGroupOfSelectors() all the way |
| 11:09 | <virtuelv> | annevk: at this point there are so many suggestions, I suggest going with magic() and blackMagic() :-P |
| 11:25 | <Dashiva> | Wow, that's a lot of names |
| 11:26 | <zcorpan_> | foo() |
| 11:29 | <annevk> | sss() and aaa() |
| 11:31 | <BenWard> | document.gifv() |
| 11:31 | <Dashiva> | dwiw? |
| 11:37 | <virtuelv> | document.gtfo() |
| 11:52 | <Lachy> | what's gifv, dwiw and gtfo? |
| 11:52 | <Dashiva> | do what I want, get the f* out |
| 11:53 | <Dashiva> | But how about making two names? E.g. both getElementsBySelector and gEBS. Then everyone should be happy :) |
| 11:54 | <Lachy> | "I guess that's the nice thing about getElementsBySelector. It's like picking 6 names all at once. :)" -- http://lists.w3.org/Archives/Public/public-webapi/2006Dec/0049.html |
| 11:55 | <Lachy> | 6 > 2! |
| 11:59 | <Philip`> | Call them $$$ and $$$s |
| 12:00 | <Lachy> | I'll just let each UA implement whatever they like and let the market decide |
| 12:00 | <Dashiva> | I know |
| 12:00 | <Dashiva> | Make them use kanji |
| 12:00 | <Dashiva> | Then they can be short and detailed at the same time! |
| 12:01 | <Lachy> | I could go with ⺽⻤() |
| 12:02 | <Lachy> | (no idea what that means, I just picked 2 random chinese characters) |
| 12:03 | <Dashiva> | Seems they didn't make it past the encoding boundries either |
| 12:03 | <Lachy> | they were encoded as UTF-8 |
| 12:03 | <Dashiva> | But that will just make it easier for authors to check they're using the right encoding! |
| 12:04 | <annevk> | yeah, someone should just implement match() and matchAll() and we're done :) |
| 12:05 | <Dashiva> | Can't we just have one method, matchBySelector and overload it? |
| 12:07 | <annevk> | hmm |
| 12:08 | <Lachy> | the reason for having the single method is that it's more efficient when you only want the first element. |
| 12:10 | <Dashiva> | Well, the JS match solves that by having a global flag on/off on the regexp. |
| 12:10 | <Philip`> | I guess it's not more efficient when you only want one element and you're selecting it by ID (which I guess might be the most common single-selection situation) |
| 12:10 | <Lachy> | the issue is that most use cases for wanting a single element are covered by gEBId or things like document.body |
| 12:11 | <Lachy> | match("#a, #b, #c") is an interesting use case when you want whichever comes first or whichever is present in the document |
| 12:11 | <annevk> | hopefully this method name is short enough that it can obsolete the need for getElementById |
| 12:12 | <annevk> | and getElementsByTagName |
| 12:12 | <Philip`> | document.match(/.e + ul li > a/g) |
| 12:13 | <Philip`> | and rewrite the ECMAScript language a bit |
| 12:14 | <Lachy> | rewrite it like E4X did? |
| 12:14 | <Lachy> | should we make E5X? |
| 12:14 | <Dashiva> | ES4 is already rewriting it plenty |
| 12:15 | <Lachy> | annevk, what was your rationality for choosing matchSingle over matchOne? |
| 12:17 | <annevk> | people argued it sounded better and I agreed |
| 12:17 | <annevk> | I'm all for .match though |
| 12:17 | <annevk> | we should make E5H |
| 12:18 | <Philip`> | I'm sure you could set up some kind of type inference to work out that "var x = /a+b/; "aaaaab".match(x)" uses regexp parsing rules when setting x, and "var x = /a+b/; document.match(x)" uses CSS selector rules, and "var x = /a+b/; "aa".match(x); document.match(x)" would be a type error with an entirely incomprehensible error message |
| 12:19 | <Lachy> | .match was the name that started this whole debate. I'm not sure going back to it would solve anything |
| 12:20 | <Lachy> | I prefer matchOne over matchSingle, but not enough to justify changing it given that there's already an implementation in base2 |
| 12:22 | <annevk> | matchOne is also harder to type on a qwerty keyboard than matchSingle |
| 12:22 | <annevk> | for me, anyway |
| 12:22 | <annevk> | but I suppose I could get used to either |
| 12:22 | <annevk> | DeanE said he could change the name btw, or alias it |
| 12:23 | <Lachy> | yeah, I know he could change it easily |
| 12:23 | <Lachy> | I don't see how One is easieer to type than Single |
| 12:30 | <annevk> | we need to add HTMLElement.isContentEditable and several things like queryCommand... on HTMLDocument... |
| 12:34 | <annevk> | queryCommandEnabled, queryCommandValue, queryCommandSupported |
| 12:39 | <Dashiva> | matchOnce? |
| 13:13 | <zcorpan_> | Hixie: comments in #writing needs to say that comments must not begin with > or -> |
| 14:33 | annevk | implemented new-style <nobr> |
| 14:34 | <annevk> | It seems end tag handling of some elements has also changed |
| 14:35 | <annevk> | most notably "/body" and "/head" |
| 14:43 | <Philip`> | Hmph, now I have enough tests that Safari won't run them all simultaneously without dropping the last couple of dozen and randomly crashing :-( |
| 14:44 | <annevk> | that's good :) |
| 14:45 | <annevk> | have you filed bugs on them already? |
| 14:45 | <annevk> | (I implemented new-style <link>, <meta>, <base> in html5lib) |
| 14:45 | <annevk> | jgraham, you need to fix the encoding sniffer for comment handling |
| 14:48 | <rubys> | found a bug in the html serializer: <p>a<b>c</p> => <p>a<b>c</p>; but only if a character encoding is specified. |
| 14:49 | <annevk> | does the html serializer implement the innerHTML algorithm? |
| 14:49 | <Philip`> | Looks like it's actually an intentional limit in WebKit - it won't display more than 200 iframes on a page |
| 14:49 | <annevk> | I honestly haven't followed all these treewalker, etc. additions |
| 14:49 | <rubys> | don't see 'inner' anywhere in the serializer. |
| 14:52 | <annevk> | maybe t.broyer should be invited on IRC... |
| 14:56 | <Philip`> | Hmm, can't do more than 200 of <object> either |
| 14:56 | <annevk> | maybe 200 object + 200 iframe? :) |
| 14:57 | <rubys> | Philip: perhaps you should get another browser? :-P |
| 14:57 | <annevk> | I wonder what the rationale is for this change: http://html5.org/tools/web-apps-tracker?from=917&to=918 |
| 14:57 | <Philip`> | Seems to be limit of 200 on num_object+num_iframe |
| 14:58 | <Philip`> | rubys: Unfortunately I can't use another browser to run test cases in Safari :-( |
| 14:59 | rubys | was joking |
| 15:00 | <Philip`> | Ooh, it even works fine in IE6 |
| 15:00 | <Philip`> | (except for failing pretty much all of the test cases, obviously) |
| 15:05 | <annevk> | you know what, I'll just implement the above change and see what happens |
| 15:09 | <Philip`> | Also, I can't even do >200 iframes by having 16 iframes each containing 16 iframes |
| 15:10 | <annevk> | that's what I was afraid of |
| 15:10 | <annevk> | no testcase breaks |
| 15:10 | <rubys> | what change? |
| 15:11 | <annevk> | see the link above |
| 15:11 | <annevk> | http://html5.org/tools/web-apps-tracker?from=917&to=918 |
| 15:12 | <Philip`> | http://trac.webkit.org/projects/webkit/browser/trunk/WebCore/html/HTMLFrameElementBase.cpp#L72 |
| 15:13 | Philip` | supposes he just has to do fewer tests at a time |
| 15:15 | <annevk> | wow, sites rely on self-references |
| 15:15 | <annevk> | I suppose the aforementioned change affects whitespace handling |
| 15:24 | <annevk> | the change also affects handling of </body><meta> for instance |
| 15:25 | <annevk> | I'm not sure this was a good change |
| 15:27 | <annevk> | mailed the list |
| 15:32 | <annevk> | changing how </p> works breaks quite a lot of tests |
| 15:41 | <annevk> | I left that change out for now |
| 15:43 | <Philip`> | Aha, it works (about half the time, randomly) in Safari if I add a button which deletes all the iframes for completed tests and then recreates the iframes for tests that haven't loaded yet, and if I then change the text size up and down so it redraws the screen properly |
| 15:43 | <Philip`> | ...which is a totally horrible hack, but then I already need another hack to replace <iframe> with <object> so that it stops being invisible in Safari |
| 15:44 | <Philip`> | (though it only does that after it's finished loading the iframes, because it looks like onload doesn't run on objects) |
| 15:44 | <annevk> | why do you recreate the iframes? |
| 15:44 | <annevk> | just set frame.location ... |
| 15:48 | <Philip`> | That doesn't appear to work (is location only set after it's decided it's acceptable to load that iframe?), but it looks like setAttribute('src', getAttribute('src')) does it, so that's a bit nicer |
| 15:49 | Philip` | should probably just split the test-report-generating page into several pages of ~100 tests, and do something cleverer on the server side to merge all the results |
| 16:15 | <annevk> | rubys, aren't < and > conforming in XML attribute values? |
| 16:21 | annevk | wonders how the hell XMLHttpRequest.responseBody works |
| 16:24 | <annevk> | here's something to play with: http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21doctype%20html%3Exxx%0D%0A%3Cscript%3E%0D%0A%20var%20r%20%3D%20new%20XMLHttpRequest%28%29%3B%0D%0A%20r.open%28%22GET%22%2C%20%22image%22%2C%20false%29%3B%0D%0A%20r.send%28%29%0D%0A%20var%20z%20%3D%20r.responseBody%3B%0D%0A%20for%20%28x%20in%20z%29%7B%0D%0A%20%20%20w%28z%5Bx%5D%29%0D%0A%20%7D%0D%0A%3C/script%3E |
| 16:25 | <gsnedders> | annevk: no, neither are conforming. [^<&>] is the definition, IIRC |
| 16:26 | <annevk> | data:text/html,<test test="<>">x</test> |
| 16:26 | <gsnedders> | actually, > is conforming. |
| 16:26 | <annevk> | please explain the lack of well-formedness error |
| 16:26 | <annevk> | oops |
| 16:26 | <annevk> | you're right |
| 16:26 | <gsnedders> | [10] AttValue ::= '"' ([^<&"] | Reference)* '"' |
| 16:26 | <annevk> | < isn't |
| 16:26 | <gsnedders> | (or with single quotes) |
| 16:26 | <annevk> | testcase should've been data:text/xml,<test test="<>">x</test> |
| 16:27 | <annevk> | they could easily allow < there... |
| 16:27 | <gsnedders> | but this is XML! |
| 16:27 | <gsnedders> | maybe due to it being a subset of SGML? |
| 16:28 | <annevk> | couldn't care less |
| 16:28 | <mitsuhiko> | is it <option selected> or <option selected="selected">? |
| 16:28 | <annevk> | either |
| 16:28 | <mitsuhiko> | awesome |
| 16:28 | <annevk> | or <option selected=""> |
| 16:28 | <mitsuhiko> | annevk: is there a preferred way? |
| 16:29 | <annevk> | not really |
| 16:29 | <gsnedders> | isn't the value irrelevant, from the UA conformance POV? |
| 16:29 | <annevk> | yes |
| 16:29 | <annevk> | from an authoring point of view it isn't though |
| 16:29 | <annevk> | it's either the empty string or the attribute name |
| 16:31 | <gsnedders> | where is that defined in the spec (as the form elements currently reference WF2 which references HTML4) or is it not yet? |
| 16:31 | <annevk> | it's defined for things like contenteditable |
| 16:31 | <annevk> | Web Forms 2 is yet to be integrated |
| 16:32 | <gsnedders> | so it's really undefined as of writing in that case |
| 16:32 | <annevk> | the writing section defines those type of attributes |
| 16:33 | <annevk> | the concept boolean attribute is defined by the HTML5 spec |
| 16:34 | <gsnedders> | it doesn't appear to be defined what happens with a bool attribute when it exists but isn't either an empty string or the attribute's name |
| 16:34 | <annevk> | it is |
| 16:34 | <rubys> | annevk: in XML, > is legal in attribute values, but < is not |
| 16:35 | <gsnedders> | annevk: where? |
| 16:35 | <annevk> | "The presence of a boolean attribute on an element represents the true value, and the absence of the attribute represents the false value." |
| 16:35 | <gsnedders> | annevk: duh. of course the next section doesn't apply. |
| 16:35 | <gsnedders> | s/section/paragraph |
| 16:36 | <annevk> | that applies just to authors, yes |
| 16:42 | <gsnedders> | hmm… you seem to be able to get the SGML handbook second-hand in good condition for less than a third of the cost of the ISO spec |
| 17:28 | <rubys> | annevk: you there? |
| 19:06 | <duryodhan> | hey, some told me this : |
| 19:06 | <duryodhan> | irefox implements the canvas element which is |
| 19:06 | <duryodhan> | actually able to catch part of the screen as bitmap and display it to |
| 19:06 | <duryodhan> | the user. It is also able to convert the bitmap to base64. |
| 19:06 | <duryodhan> | *firefox |
| 19:06 | <duryodhan> | is this true? |
| 19:06 | <duryodhan> | about the canvas element? |
| 19:08 | <Dashiva> | Safari, Opera and Firefox all implement canvas |
| 19:09 | <duryodhan> | yes ... |
| 19:09 | <duryodhan> | I know that ... |
| 19:09 | <duryodhan> | I am saying can Canvas do that ... |
| 19:09 | <duryodhan> | (save a part of page as bitmap and then save it as base64) |
| 19:10 | <Dashiva> | You mean basically print-screen the page and then work with that? |
| 19:10 | <duryodhan> | yeah |
| 19:10 | <duryodhan> | kinda |
| 19:10 | <Philip`> | Firefox has a non-standard extension which lets privileged content (like extensions) draw HTML elements into the canvas |
| 19:11 | <duryodhan> | where? |
| 19:11 | <Philip`> | (which I believe is used by e.g. the tab preview extension) |
| 19:11 | <bewest> | yeah, a lot of people who prorivide screenshot services use that feature |
| 19:11 | <duryodhan> | so can I do it through HTML + JS ? |
| 19:12 | <duryodhan> | or will it always require an extension? |
| 19:12 | <duryodhan> | and can it convert it to base64 |
| 19:13 | <Philip`> | I can't see any documentation, but it looks like it's ctx.drawWindow(htmlelement, x, y, w, h, backgroundcolour) |
| 19:13 | <Philip`> | but you'll always get a security exception if you try doing that from normal web content |
| 19:14 | <duryodhan> | but if user adds the domain to trusted ... do you still get that ? |
| 19:15 | <Philip`> | That still won't let it run; though I think it's possible to make web content ask the user for universal read privileges, in which case it would be allowed |
| 19:15 | <Philip`> | (though you probably have to be a trusted site before even being able to ask for permission) |
| 19:16 | <Philip`> | (and you have to ask for permission every time you want to use drawWindow) |
| 19:16 | <duryodhan> | ohh |
| 19:16 | <duryodhan> | stupid mozilla server has klined me :( |
| 19:16 | <Philip`> | netscape.security.PrivilegeManager.enablePrivilege('UniversalBrowserRead'); |
| 19:17 | <Philip`> | ...should give the right privileges, I think |
| 19:19 | <Philip`> | Once you've drawn stuff to the canvas, http://www.whatwg.org/specs/web-apps/current-work/multipage/section-the-canvas.html#todataurl lets you save it as a bitmap (as a base64-encoded PNG image in a data: URI) |
| 19:20 | <duryodhan> | hmm let me try it out then .... |
| 19:20 | Philip` | wonders if people have already complained about Gecko adding non-standard functions to the '2d' context, instead of making a 'moz-2d' |
| 19:22 | <Philip`> | (...and adding non-standard arguments to the toDataURL function) |
| 19:23 | <duryodhan> | Philip`: what is the ctx in the ctx.drawwindow ? |
| 19:23 | <Philip`> | ctx = canvas.getContext('2d') |
| 19:23 | <Philip`> | where canvas is a <canvas> element |
| 19:24 | <Philip`> | (...which should be big enough to fit whatever you want to draw into it) |
| 19:24 | <duryodhan> | and the html element is lets say div ? or is it canvas again? |
| 19:25 | <Philip`> | (You can do 'canvas = document.createElement('canvas'); canvas.width = 123; canvas.height = 456' if you want a canvas element without actually having one in the HTML document) |
| 19:26 | <Philip`> | The htmlelement in the first argument to drawWindow can be any HTML element at all |
| 19:26 | <Philip`> | or at least I assume it can be - I've never actually tried this myself :-) |
| 19:27 | <Philip`> | http://weblogs.mozillazine.org/roc/archives/2005/05/rendering_web_p.html has an example using drawWindow, and it looks like the interface hasn't changed since then |
| 19:36 | <duryodhan> | http://pastebin.ca/579563 |
| 19:36 | <duryodhan> | us that ok? |
| 19:36 | <duryodhan> | how do I get the png file ? |
| 19:54 | <Philip`> | duryodhan: Hmm, looks like I was wrong about it accepting any HTML element - it has to be a window object |
| 19:55 | <Philip`> | http://canvex.lazyilluminati.com/misc/drawwindow.html (when run from local disk so it's more-trusted) seems to work for me |
| 19:55 | <Philip`> | It draws the whole page window into the canvas, and then uses toDataURL to get an address which can be used in <img src> or could be parsed to get the actual PNG data |
| 20:00 | <duryodhan> | Philip`: ohh ok |
| 20:00 | <duryodhan> | it works for me too... |
| 20:00 | <duryodhan> | but then the problem is still there ... |
| 20:01 | <duryodhan> | I don't think an actual page can do this cos it requires that page be on local disk |
| 20:01 | <duryodhan> | btw, |
| 20:01 | <duryodhan> | it is showing it to me twice ... |
| 20:02 | <Philip`> | Is there some way to mark pages as trusted in FF? That ought to make it work the same as files on disk, I think, though I can't work out where you find that option |
| 20:03 | <Philip`> | It should be showing the original text once, and then the rendered version in the <canvas>, and then the toDataURLd version in the <img> just to the right |
| 20:03 | <duryodhan> | yes |
| 20:03 | <duryodhan> | thats right |
| 20:09 | <duryodhan> | maybe you have to make the html+script signed , package them as jar files with signtool and then access them... |
| 20:09 | <duryodhan> | http://www.mozilla.org/projects/security/components/signed-scripts.html |
| 20:09 | <duryodhan> | search for using signtool in that |
| 20:09 | <Philip`> | Hmm, sounds painful |
| 20:09 | <duryodhan> | yeah |
| 20:10 | <duryodhan> | for the devel |
| 20:10 | <duryodhan> | not for the client |
| 20:10 | <Philip`> | Sounds like it might be easier just to write an extension, particularly since that could avoid asking the user for permission every time |
| 20:11 | <duryodhan> | an extension that does what ? |
| 20:11 | <duryodhan> | takes a snap when told and saves it |
| 20:11 | <duryodhan> | suppose I want to submit the base64 to the server (of the canvas) |
| 20:11 | <duryodhan> | in a form ... |
| 20:15 | <Philip`> | An extension that does whatever you're trying to do that Firefox normally objects to |
| 20:16 | <Philip`> | You should be able to just call toDataURL and put the resulting string in a form field and submit that, though you'll probably have to strip off the "data:image/png;base64," before trying to decode it into a real PNG |
| 20:16 | <Philip`> | (It's not guaranteed to be base64, but I don't know of any implementation that doesn't do that, and you can't do drawWindow in a vaguely cross-browser way anyway) |
| 20:20 | <zcorpan> | seems like ie stops appending characters to the string when getting innerHTML after it has dealt with the children of a plaintext element |
| 20:20 | <zcorpan> | hmm, wc |
| 20:58 | <jgraham> | annevk: Can you file a bug on me about the character encoding change? I am really swamped with stuff at the moment so I'm missing out on all the html5lib fun :( |
| 21:11 | <Hixie> | i really have no idea how to describe the rules for CDATA and RCDATA |
| 21:11 | <Hixie> | for authors |
| 21:21 | <hsivonen> | Hixie: delegate to tutorial volunteers perhaps to see what they come up with? |
| 21:29 | <Hixie> | while i am sure that what they would come up with would be quite helpful to authors, i don't think it would be airtight |
| 21:30 | <hsivonen> | yeah. |
| 21:30 | <hsivonen> | it seems that few people appreciate the airtight restatement in prose :-( |
| 21:31 | Philip` | wonders how to test (and report results for) optional features, like gradient rendering, where there are different requirements if the feature is not supported, but there's no way to really tell whether the UA is actually trying to support the feature (but buggily) or intentionally and consistently choosing to not support it |
| 21:31 | <Hixie> | hsivonen: the target audience of the syntax section is basically me -- or rather, spec lawyers in years to come. i don't want them to have to prove their case about whether something is conforming or not by walking the parsing algorithm |
| 21:33 | <hsivonen> | Hixie: I understand. I'd expect those who markp calls "assholes" to prefer airtight prose over walking the algorithm |
| 21:35 | <Hixie> | yeah |
| 21:35 | <hsivonen> | Hixie: perhaps define them in terms of a sequence of subparts like "escaped run", "unescaped text", "entity" |
| 21:35 | <Hixie> | that's basically the target audience |
| 21:36 | <Hixie> | yeah, i think i'll basically have to do that |
| 21:36 | <Hixie> | though not with the word "entity"! |
| 21:36 | <hsivonen> | well entity reference |
| 21:36 | <hsivonen> | for RCDATA |
| 21:37 | <Hixie> | oh right |
| 21:37 | <Hixie> | indeed |
| 23:38 | <zcorpan> | http://www.bernzilla.com/item.php?id=875 |
| 23:40 | <Hixie> | oops |
| 23:40 | Hixie | replies to a mail without noticing it was sent to a mailing list |
| 23:40 | Hixie | whistles innocently and moves on to the next mail |
| 23:41 | <Hixie> | zcorpan: hey, finally someone who agrees with me! |
| 23:41 | <zcorpan> | Hixie: yeah :) |
| 23:43 | <zcorpan> | actually, i feel "dirty" too, i just think that it's not really harmful and authors changing their documents to insert div tags around images to conform to html5 are wasting their time |
| 23:43 | <Hixie> | i was talking to citoyen yesterday about this |
| 23:43 | <Hixie> | the only reason we have <div> is to allow custom widgets to be made |
| 23:44 | <Hixie> | i can't work out how to make it hard to abuse it |
| 23:47 | <zcorpan> | if you make it hard to abuse div, people will abuse something else... :) |
| 23:47 | <zcorpan> | (like table) |
| 23:48 | <Hixie> | <table>, <br>, and <div> are the main ones i'm worried about being abused |
| 23:48 | <Hixie> | <table> is being dealt with by education |
| 23:49 | <Hixie> | moderately successfully, even |
| 23:51 | <zcorpan> | <br> is a tough one. i don't know how to not use <br> in a forum that accepts bbcode. people want to be able to make one, two, three, many line-breaks. fwiw, they also aren't going to mark up headings in any other manner than pressing the BOLD button and hitting enter |
| 23:52 | <zcorpan> | (well, i guess a heading bbcode tag could be introduced -- that was an aside) |
| 23:53 | <Hixie> | the contents of forum postings are equivalent to wysiwyg editor output |
| 23:53 | <zcorpan> | yeah |
| 23:53 | <Hixie> | i don't know how to handle those either |
| 23:53 | <zcorpan> | it's not trivial |
| 23:53 | <Hixie> | the <meta generator> idea didn't go down well |
| 23:53 | <zcorpan> | indeed |
| 23:56 | <zcorpan> | about div and what it means... perhaps when it contains block-level content, it means nothing, and when it contains inline-level content, it means a thematic group |
| 23:57 | <zcorpan> | or it always means a thematic group |
| 23:57 | <Hixie> | isn't that what <section> is? |
| 23:57 | <zcorpan> | section affects the document outline, div doesn't |
| 23:58 | <Hixie> | i suppose i could buy your block vs inline semantics definition |
| 23:59 | <Hixie> | but when it contains blocks, it really means nothing, imho |
| 23:59 | <Hixie> | that, btw, is why i didn't want it containing inlines in the first place |
| 23:59 | <zcorpan> | yeah |
