| 22:56 | <annevk> | and the overloading <object> debate continues |
| 22:56 | <annevk> | yay |
| 22:56 | <othermaciej> | w00t |
| 22:57 | <annevk> | othermaciej, btw, you think we should add the constants to XMLHttpRequest? |
| 23:02 | <othermaciej> | annevk: I don't really have a strong opinion |
| 23:02 | <othermaciej> | they seem nice, but not absolutely necessary |
| 23:03 | annevk | doesn't really care either |
| 23:03 | <annevk> | but it's trivial to add them in the spec |
| 23:03 | <annevk> | and prolly trivial in implementations too |
| 23:04 | twanj | (n=chatzill⊙chfcn) Quit (Read error: 60 (Operation timed out)) |
| 23:06 | annevk | asks some other implementors |
| 23:07 | <othermaciej> | it is more typical DOM practice to have named constants and not just bare numbers with special meanings for things like this |
| 23:08 | <annevk> | yup |
| 23:11 | <Dashiva> | And the longer the better |
| 23:11 | <othermaciej> | I don't understand why people think <object> is a good thing |
| 23:11 | <othermaciej> | "I'm including something" doesn't seem very semantically meaningful |
| 23:12 | <othermaciej> | making things more generic runs counter to the very idea of semantic markup |
| 23:12 | <Dashiva> | I don't think it's on semantical grounds, more for simplicity and fear of redundance (my guesswork only, of course) |
| 23:12 | <Hixie> | <object> is anything but simple |
| 23:13 | <othermaciej> | <object> is possibly the most complex element in all of HTML |
| 23:13 | <Dashiva> | But not changing the status quo is simpler than doing so |
| 23:14 | <Hixie> | maybe we should drop <object> from HTML5 altogether |
| 23:14 | Hixie | ducks |
| 23:14 | <Dashiva> | heh |
| 23:14 | <othermaciej> | heh |
| 23:14 | <Dashiva> | I'm sure macromedia would love that |
| 23:14 | <Hixie> | we have <embed> for plugins |
| 23:14 | <othermaciej> | Hixie: is there a list anywhere of which elements HTML5 drops or deprecates that are in HTML4? Is that on the wiki? |
| 23:15 | <Hixie> | dunno off hand, there might be |
| 23:15 | <annevk> | <embed> works better for Flash than <object> anyway |
| 23:15 | <Dashiva> | Does object serve any purposes that aren't served by specific elements? |
| 23:15 | hasather | (n=hasather⊙8ttc) Quit (Read error: 104 (Connection reset by peer)) |
| 23:15 | <Dashiva> | iframe, img, video eats up a lot of it |
| 23:15 | <Dashiva> | If embed handles plugins, what's left? |
| 23:15 | hasather | (n=hasather⊙8ttc) Quit (Remote closed the connection) |
| 23:16 | <annevk> | audio... |
| 23:16 | <annevk> | but there's an API for that |
| 23:16 | <Hixie> | we have Audio() for that |
| 23:16 | <Hixie> | (i don't really undertand how <audio> would make sense) |
| 23:16 | <annevk> | after thinking about it some more me neither |
| 23:16 | <Dashiva> | For playing music? |
| 23:16 | <othermaciej> | I think <audio> makes sense |
| 23:16 | <annevk> | how would it work? |
| 23:17 | <Dashiva> | Like embed, or bgsound if you want |
| 23:17 | <Hixie> | othermaciej: what does it represent? |
| 23:17 | <annevk> | if it's about the UI you just want a declarative interface to Audio() through buttons or something |
| 23:17 | <othermaciej> | it represents an embedded semantic/foreground sound, analogous to img and video |
| 23:17 | <annevk> | othermaciej, http://wiki.whatwg.org/wiki/HTML_vs._XHTML#Markup_2 has element and attribute changes |
| 23:17 | <Dashiva> | Well, it frees you from depending on scripts |
| 23:17 | <annevk> | might not be up to date |
| 23:17 | <othermaciej> | this will be easier to discuss on Monday so I'll hold off for now |
| 23:18 | <Hixie> | crap gotta go ref the finals |
| 23:18 | <Hixie> | bbiab |
| 23:18 | <Dashiva> | annevk: I see it sort of like event-source |
| 23:19 | <othermaciej> | wow, "target" attribute is removed? |
| 23:19 | <annevk> | it was recently added again I think |
| 23:19 | <annevk> | i'll fix that |
| 23:20 | <othermaciej> | most of the obsolete attributes seem rightfully obsoleted, but many of the obsolete elements are in the "browsers will have to implement these anyway" category |
| 23:21 | <met_> | osolete Elements: acronym (use <abbr> instead) = reason for this? |
| 23:21 | <annevk> | those will prolly be in the rendering section for exactly that reason |
| 23:21 | <annevk> | met_, there's no real useful difference and authors are constantly confused as to which to use |
| 23:21 | <othermaciej> | met_: please see archives of the many debates on this |
| 23:21 | <annevk> | othermaciej, just like the parsing section handles all elements the rendering section will (hopefully anyway) too |
| 23:22 | <othermaciej> | annevk: maybe there should be some category of elements that conformant implementations must implement, but which can never appear in a conformant document and must be rejected by conformance checkers |
| 23:22 | <othermaciej> | like a stronger version of deprecation |
| 23:22 | <othermaciej> | I don't think relegating it to the conformance section makes sense, since in some cases the API may matter too |
| 23:22 | <annevk> | othermaciej, yes, that's what I said :) |
| 23:22 | <met_> | othermaciej, any way how to fullsearch mailing list other than google site:lists.whatwg.org ? |
| 23:22 | <annevk> | rendering section only applies to implementors |
| 23:22 | <othermaciej> | although I suppose defining the content model for an intrinsically nonconformant element is kinda pointless |
| 23:23 | <annevk> | yup |
| 23:23 | <annevk> | you just need parsing + rendering |
| 23:23 | <othermaciej> | annevk: maybe it shouldn't be called "rendering" if it might contain APIs and attribute definitions |
| 23:23 | <othermaciej> | you need parsing, rendering, how to interpret the attributes, etc |
| 23:23 | <annevk> | oh, dunno about APIs |
| 23:23 | <othermaciej> | met_: I dunno |
| 23:23 | <annevk> | for <body> and such you'd have to define a lot of additional stuff too then |
| 23:24 | <annevk> | (for instance) |
| 23:24 | <annevk> | link@target and form@target are still on the page as they're not defined yet |
| 23:25 | <annevk> | <font> is also in HTML5 |
| 23:27 | <annevk> | fixed that too |
| 23:28 | <met_> | not sure about acronym dropping, but ok I can live without it 8-), but general question from this |
| 23:28 | <met_> | many people will ask "why you drop this", "why you add this" etc. etc. and there is no other answer than "see in mailing list archive". |
| 23:28 | <met_> | may be there is need from "something" faq, wiki answers, dunno, otherwise you will see "why you drop acronym" and other questions for hundred and hundred times |
| 23:29 | hasather_ | (n=hasather⊙8ttc) Quit (Remote closed the connection) |
| 23:29 | <annevk> | you are free to do so |
| 23:29 | <annevk> | encouraged even |
| 23:30 | <met_> | not sure if i am the right person, still do not orientate in spec enough |
| 23:30 | <met_> | btw full text mailing list search exists at http://lists.whatwg.org/pipermail/whatwg-whatwg.org/ |
| 23:31 | icaaq | calls it in for the night. Kepp up the good work :) |
| 23:34 | hasather | (n=hasather⊙8ttc) Quit (Read error: 110 (Connection timed out)) |
| 23:34 | annevk | uses "g <string> inurl:whatwg-whatwg" for searching mostly |
| 23:38 | annevk | -> bed |
| 23:53 | met_ | (n=Hassman⊙rnuc) Quit ("Chemists never die, they just stop reacting.") |
| 23:53 | hasather_ | (n=hasather⊙8ttc) has left #whatwg |
| 23:56 | <Hixie> | othermaciej: yeah don't worry in due course we'll be defining all the various elements that browsers have to support |
| 23:56 | <Hixie> | othermaciej: but they won't be "HTML5" |
| 23:56 | <Hixie> | othermaciej: (the parsing section already does this -- it defines parsing for dozens of obsolete elements) |
| 23:58 | <Hixie> | othermaciej: i guess <audio> could make sense if it implies ui controls (unlike <video> which doesn't in v1, though probably would in v2) |