10:22:10 SM: 2 votes for restoring A.3 10:22:29 RM: don't object, but understand distinction WG members making, but not sure authors care about 10:22:39 SP: then say "elements that can only be empty" 10:23:00 RM: some elements can only be empty; list them and what can do with them 10:23:07 SM: elements that can never have content? 10:23:10 SP: works for me 10:23:15 +1 10:23:35 SM: Elements that can never have content versus Elements that may not contain content 10:23:40 +1 10:23:44 GJR +1 10:24:01 RM: when do scripting, do certain things (but that topic for later) 10:24:11 SM: script example in restored A.3? 10:24:28 SM: trying to capture ideas in draft - will update later 10:24:53 SM: A.4 "A.4. Embedded Style Sheets and Scripts" say "do" but not "do not" 10:24:58 RM: needs balance 10:25:35 TH: why not say use external stylesheets and scripts - XHTML in HTML compatability mode, use external scripts 10:25:49 SM: unreasonable burden if all one is doing is adding a few localized styles 10:26:01 RM: override one style with another for single document instance 10:26:38 RM: example would be helpful - if use pointy brackets have to do like this in order to work, but easier to create and maintain external stylesheets 10:27:27 SP: problem can arise if content gets fed through XSLT first - protecting documents; what we warn about could happen - authors should be aware 10:28:03 GJR notes that FireVox cannot process external stylesheets but only embedded or inline CSS3-speech values 10:28:29 SM: A.5 A.5. Line Breaks within Attribute Values - dont' know why anyone would care 10:28:59 TH: some probably process new lines specially 10:29:13 TH: as long as is CDATA should ignore new lines 10:29:24 SM: so if datatypes IDREFs wouldn't be legal 10:29:34 SM: fine guideline, but don't know origin -- needs a do 10:29:36 RM: yes 10:30:26 RM: has this problem been mitigated over the years? 10:30:44 RM: perhaps confusion is that problem was limited and long time ago 10:30:57 SM: not a bad rule, but next rule is candidate for deletion 10:31:10 SM: A.6. isindex - who uses them? 10:31:18 GJR: deprecated in HTML4 anyway 10:31:45 SM: original text wrong - no more than one ISINDEX element is a no brainer 10:31:50 SM: would remove A.6 10:31:52 SP: ok 10:31:56 Alessio: ok 10:31:59 GJR: ok 10:32:27 SM: kept these consistent with Appendix C - even down to fragment IDs 10:32:35 RM: can log changed 10:32:43 SM: change number? 10:33:04 TH: use DEL to show A.6 no longer applicable 10:33:16 SM: renumber 10:33:18 SP: good 10:33:35 SM: A.7. The lang and xml:lang Attributes - may be controversial 10:34:10 TH: tool looks at doctype then tries to figure out lang attribute 10:34:19 -Gregory_Rosmaita 10:34:56 I have no problem with the lang and xml:lang 10:35:11 scribe: Steven 10:35:35 TH: I'm worried that tools that see it's HTML: will go looking for @lang 10:35:38 dropped the phone - must have disconnected 10:36:06 ATs key off of lang - if try just xml:lang, won't switch natural langauges - can log as bug with GNOME's Orca 10:36:14 Yam: I'm not sure about this issue 10:36:35 +Gregory_Rosmaita 10:36:37 ... we are thinking about removing @lang 10:36:47 ... but CSS selectors may use it (for instance) 10:36:54 ... we have no strong position though 10:37:14 scribe: oedipus 10:37:59 need to find CSS selector example that uses aria live regions to change language of text 10:38:09 SM: need portable way to indicated language change 10:38:36 Yam: existing UA implementations use @lang for CSS selectors - we discourage use of that for XHTML family of languages consistency of use 10:39:07 RM: people using lang specifically, can't write XHTML 1.1 or 1.2 document with @lang 10:39:23 SM: want to ensure rule works before ship XHTML2 10:39:30 SM: could reintroduce lang 10:39:34 RM: perhaps target 10:39:59 GJR: AT problem is DOM calls and limitations AT-side on what it relies upon to key natural language switches 10:40:28 SP: if need compatability GLs to serve as HTML need lang, but in XHTML lang means nothing and is just there for convenience 10:40:52 SM: normatively state allow @lang but if doc served as XHTML @lang must be ignored? 10:41:17 SP: yes, no meaning in XHTML - only there for convenience of being able to serve XHTML documents to legacy browsers 10:41:21 RM: synonyms? 10:41:30 SP: then people might stop using xml:lang 10:41:37 RM: rammifications? 10:42:32 SM: CSS selectors based on lang when have both lang and xml:lang - XHTML 1.1 document, for example, serving document in either media type, how to craft css selectors to make everything in latin pink and italic given i'm using lang and xml:lang 10:43:07 SP: no, use coma as delimeter -- CSS doesn't select on attribute - in HTML uses lang, in XHTML uses xml:lang, so only one rule in CSS 10:43:17 TH: could use CSS rule to key on @lang specifically 10:44:21 SP: CSS has knowledge of language text is in due to selector - language comes from parent element of current element; if current element is in latin, do this - only way to do in CSS anyway 10:44:56 SP: no selector that says if parent of current element has @blah ... 10:45:58 TH: selecing on lang attribute correct thing to do according to CSS 10:46:07 SP: can have select on lang and xml:lang 10:46:27 TH: people today select on lang - problem is HTML compatibility GLs 10:46:38 SP: why i'm suggesting we add lang back into the languages 10:46:48 GJR plus 1 to readding @lang 10:46:57 q+ about how we support @lang via M12N 10:47:22 TH: if people transformed to HTML would be easier 10:47:38 TH: if transform from xml:lang to lang 10:47:50 SP: what is easier 10:48:01 TH: don't need to put lang into XHTML Base 10:48:42 SM: 2 sets of constituents to serve: one of them is "the great unwashed" - just have a simple site who want simple solutions; then there are sites such as amazon, which have FAR more resources can bring to bear 10:48:56 SP: but don't want to transform everytime serve page 10:49:07 SM: cache it 10:49:21 RM: can i? if getting weather updated every 5 seconds, may never be cached 10:49:27 q+ to discuss how we support @lang via M12N 10:49:28 SM: cached for 5 seconds 10:49:48 RM: a lot of transformation for 5 seconds 10:50:30 SM: if permit lang along lines SP discussed - technically, how do we do that? 10:50:44 SM: or introduce new lang module? 10:51:10 SP: yeah, or may need other attributes, in which case a "compatability module" would be the answer 10:51:20 Yam: have legacy module, right? 10:51:29 SP: don't want to allow BLINK along with @lang 10:51:42 -yamx 10:51:59 SM: lang not in legacy module now, so wouldn't be conflict if introduced elsewhere 10:52:23 SM: could introduce an HTML compatibility module as update to 1.1 10:52:24 +??P4 10:52:34 i killed line by mistake 10:52:37 zakim, ??P4 is Yam 10:52:37 +Yam; got it 10:52:38 Zakim, ??P4 is yamx 10:52:39 I already had ??P4 as Yam, yamx 10:52:50 OK, zakim, thanks. 10:52:53 SM: compatibility GLs wouldn't be useful for 1.1 10:53:03 SP: better off using 1.2 anyway 10:53:08 RM: definitely 10:53:44 SM: for this GL, "do use lang" - or "do use both" - realize can't if doing 1.1, Basic, +RDFa, etc 10:54:04 TH: need to put responsibility on author - use both 10:54:13 GJR: same thing authors do with name and id 10:54:52 SM: will update appropriately and then need to figure out how to help languages support both of these, but that is independent discusssion 10:55:08 SM: "A.8. Fragment Identifiers" - not controversial 10:55:10 TH: no 10:55:40 SP: when wrote A.8 there were UAs that didn't recognize ID, but that has changed 10:55:44 SM: and i changed the doc 10:56:09 SM: "A.9. Character Encoding" 10:56:14 SM: interesting problem 10:56:26 Yam: Japanese example would be useful 10:56:29 SM: true 10:56:56 SP: including mediatype and encoding in same metadata bad choice made way back when 10:57:22 RM: there is a default - if satisfied with default, don't need to do this 10:58:06 TH: back to HTTP spec - not possible - HTTP content type can be set as much as you want, but often receive US ASCII from server 10:58:25 SM: if accessing document in filesystem not possible 10:58:34 TH: author can't change content type served by server 10:59:20 And some protocol;s don't support encodings, eg ftp, file: 10:59:28 s/;/'/ 10:59:28 TH: can't change content type set by server; practical problem; really ought to set on server - should stress 10:59:43 s/protocol's/protocols/ 11:00:05 SM: if doc coming from server, character encoding is specified in response, so is authoritative, and may even override XML declaration 11:00:07 TH: yes 11:00:17 SM: telling people not to use XML declaratoin 11:00:33 TH: bigger problem if send as XHTML and don't have control over encoding and content type 11:01:35 SM: serious problem - compatability GLs and content negotiation only relevant when have access to server and ability to control headers otherwise nothing we say matters 11:01:52 TH: some think HTTP-EQUIV panacea; still sending as text/html 11:02:02 really true 11:02:28 SP: HTML4 spec says that server should look at HTTP-EQUIV and send appropriate, but never implemented 11:02:51 SP: GL should be "when serving a document, putting anything in the document that is unlikely to help because server always has priority" 11:02:58 TH: also not to expect something else 11:03:08 SP: META unlikely to help you at all 11:03:12 SM: maybe not mention 11:03:17 SP: should to make explicit 11:03:29 RM: first item similar 11:04:00 SM: suggestion: could we have 2 rules: when document being sent from server, do this 11:04:12 SM: when document being accessed directly do this 11:04:31 Default for XML is UTF-8, right? 11:04:41 TH: even when served by HTTP daemon, even if proper content type served, save as HTML 11:04:55 yes, steven 11:05:32 TH: legacy issue; if not serving direct from server, use HTTP-EQUIV as per spec, but if set content type and char encoding on server 11:05:39 RM: not an isolated issue 11:06:00 SM: why don't we just say - ifyou want to be compatible encode as UTF-8 or UTF-16 11:06:03 RM: agree 11:06:13 SP: and state ensure that server serves it as UTF-8 11:06:14 +1 11:06:19 plus 1 11:06:43 RM: happy with that solution 11:06:58 SM: if want docs to be protable, encode in UTF-8 or UTF-16 11:07:21 s/protable/portable 11:07:40 SP: people should use UTF-8 everywhere ideally 11:08:23 TH: make sure server announces correctly needs to be in GL 11:09:10 http://www.w3.org/html/wg/html5/#charset 11:09:34 HTML5: "If the document contains a meta element with a charset attribute or a meta element in the Encoding declaration state, then the character encoding used must be an ASCII-compatible character encoding. " 11:10:09 SM: HTML5 talking about default when no server - we say use META HTTP-EQUIV 11:10:24 HTML5: "If the document does not start with a BOM, and if its encoding is not explicitly given by Content-Type metadata, then the character encoding used must be an ASCII-compatible character encoding, and, in addition, if that encoding isn't US-ASCII itself, then the encoding must be specified using a meta element with a charset attribute or a meta element in the Encoding declaration state. " 11:10:46 SP: anyone actually look at HTTP-EQUIV 11:10:51 SM: browsers do 11:11:00 TH: most commonly used browsers do 11:11:27 TH: issue is what is use they make of it - some ignore content type based on extension 11:11:45 Yam: use META HTTP-EQUIV to ensure japanese encoding 11:12:04 Yam: all Japanese encoding should be in meta http-equiv 11:12:11 SM: that overrides HTTP headers? 11:12:32 Yam: not sure; easier for carrier to serve 11:12:59 SM: A.10. Boolean Attributes 11:13:04 SM: controversy? 11:13:10 RM: looks good 11:13:29 SM: A.11. Document Object Model and XHTML 11:13:49 Alessio: can get to HTML DOM as well 11:14:05 SM: will remove "if is really true" editorial note 11:14:18 TH: as long as works with HTML4 UAs don;t have problem 11:14:33 SM: A.12. Using Ampersands 11:14:57 fine with GJR 11:15:14 SP: sentence difficult to read - AND in all caps 11:15:24 SP: change AND to lower case 11:15:30 TH: possibly STRONG? 11:15:49 TH: if possible, use semi-colon instead of ampersands in URIs 11:16:35 SM: made change to case of "and" 11:17:16 deane has joined #xhtml 11:17:20 GJR: plus an abbr expansion for & & 11:17:52 SM: when using ampersand in URI use its escaped form 11:17:53 SM: A.13. Cascading Style Sheets (CSS) and XHTML 11:18:01 SM: may have over-simplified 11:18:10 RM: may want to make comment on lang here 11:18:23 SP: CSS selector on xml:lang rather than lang 11:18:45 SM: do nots needed? 11:18:50 RM: inverse fairly obvious 11:19:09 SM: added thing about style HTML element 11:19:30 SM: in HTML style on body becomes style for entire viewport; in XML does not 11:19:45 TH: change Do rule - if need to set, then... 11:20:46 SP: special rule in CSS is because early versions of IE didn't have style for HTML element, so CSS states, style BODY element 11:20:52 SM: do style HTML element? 11:21:06 SP: no, for compatability reasons, style BODY rather than HTML element 11:21:28 SM: style applies only to block not whole window 11:22:04 SP: if you want to remove styling put on HTML, have to define style for HTML, but this might be the ocassion to say "this is an old rule" 11:22:26 SP: when wrote, were browsers that didn't support HTML 11:22:30 SM: just added this 11:22:54 RM: implications - example of consequences - we need to make clear what consequences are 11:23:44 SM: good point, Roland; maybe not even necessary to say this; authors put style on BODY, not HEAD; and when served as HTML style on BODY apply to entire window 11:24:00 SP: what CSS spec says, but not reality; 2px margin around HTML element 11:24:37 SP: why can't i get rid of margin around my HTML document - reason: have to explicitly state padding:0;margin:0 11:24:42 SM: do we need this rule? 11:24:44 SP: no 11:25:06 TH: need rule to point this out 11:25:28 RM: rationale needs more work - particularly important for this appendix a section 11:25:36 SM: will try to update so can revisit later 11:26:14 SM: had been telling people to use xml style declarations, and i think we should tell people not to use them for compatibility 11:26:37 SM: A.15. White Space Characters in HTML vs. XML 11:26:57 SM: should change name from "white space" 11:27:00 SP: agreee 11:27:08 SM: A.16. The Named Character Reference ' 11:27:36 TH: typographcally, is right single quote - no problem with A.16, but shouldn't get into typography side of it 11:27:37 SM: ok 11:28:14 ===== ADJOURN FOR LUNCH - RETURN in 77 Minutes (quarter to next hour ====== 11:28:19 rrsagent, make minutes 11:28:19 I have made the request to generate http://www.w3.org/2008/06/18-xhtml-minutes.html oedipus 11:28:19 -ShaneM 11:28:20 -Steven 11:28:24 -Yam 11:28:25 -Tina 11:28:26 -Gregory_Rosmaita 11:28:26 -Roland 11:28:28 -Alessio 11:28:30 IA_XHTML2()4:00AM has ended 11:28:32 Attendees were Roland, Steven, Gregory_Rosmaita, yamx, ShaneM, Alessio, Tina, Yam 11:39:17 oedipus_laptop has joined #xhtml 12:20:26 alessio has joined #xhtml 12:30:40 ShaneM has joined #xhtml 12:44:07 IA_XHTML2()4:00AM has now started 12:44:14 +Roland 12:44:42 +ShaneM 12:45:12 OK, I will join, too. 12:45:34 zakim, dial steven-617 12:45:34 ok, Steven; the call is being made 12:45:36 +Steven 12:45:49 +Gregory_Rosmaita 12:45:53 +??P8 12:46:06 zakim, ??P8 is Yam 12:46:06 +Yam; got it 12:46:17 Thanks. 12:46:18 +??P9 12:46:22 zakim, ??P9 12:46:22 I don't understand '??P9', alessio 12:46:22 my pleasure 12:46:26 zakim, ??P9 is Alessio 12:46:26 +Alessio; got it 12:46:35 +Tina 12:47:21 SP: complete discussion of media types? 12:47:28 SM: enough to create a new draft 12:47:42 RM: one other thing: validator thing olivier brought up 12:47:49 Olivier says: Good. How about: 12:47:49 - [now] updating the tool to match the draft guidelines in the ED of xhtmlmime 12:47:49 - [soon] including the checks into the validator, mark them as [experimental], informative, whatever. That will provide us with better and more feedback than just a WD. 12:47:56 SM: his proposal to me this morning appears above 12:48:29 RM: something we'd like to see, isn't it? 12:49:05 RM: do we believe running through validator to get info if suitable to be served? 12:49:24 GJR thinks would promote awareness 12:49:29 yes 12:50:29 SM: concern is "validator as holy writ" -- good or bad, depending upon whether it works; would be more comfortable if could provide WG resources to work on that 12:50:47 (that being validator and control over changes) 12:51:08 SP: depends on how they present information -- warnings versus errors 12:51:16 RM: that is what they did 12:51:55 SM: get document updated to reflect discussion today; respond to olivier that WG ok with warnings 12:52:20 GJR would like a STRICT mode where errors are reported as errors 12:52:39 SM: open source tool 12:52:57 RM: anyone can hack anytime want to; what is in w3c validator he takes care of 12:53:37 ACTION: Shane to finish the updating the XHTMLMIME draft then respond to Olivier's proposal. 12:53:45 RM: anything anyone wants to mention in closing on mime doc? 12:54:06 TOPIC: XHTML 1.n (Follow on to 1.1) 12:54:46 RM: have 1.1 spec waiting for modularization; proposed change adding target attribute back in, which is considered not in scope of what should do in new edition 12:54:51 RM: what do we do next? 12:54:59 RM: drop from second edition? 12:55:11 RM: release XHTML 1.n and if so what would be in it? 12:55:49 SP: adding @target to 1.1 is that Basic needs -- 1.1 should be considered full Basic with all facets of Basic 12:56:13 TH: @target to open frame or new window? 12:56:22 TH: no reason to put into declarative markup language 12:56:28 SM: why is target not useful 12:56:37 TH: authors shouldn't force new windows 12:56:45 TH: if in XFrames, ok, but not in Basic 12:57:08 GJR notes that handling of @target is user agent control issue being addressed in UAAG2.0 12:57:23 TH: opening windows outside scope of declarative language 12:57:49 Yam: against using target, but made compromise with CDF or another WG who demanded it be restored; don't think we need it 12:57:55 SP: SVG or CDF? 12:58:02 SP: doesn't SVG need it in some way? 12:58:24 RM: compatability guide question -- html mime --- inhibiter for those trying to move from HTML to XML 12:58:32 SP: reasonalbe use cases for @target 12:58:54 SP: list of search results - click on a search result to get result without changing underlying doc 12:58:59 TH: UA has built in 12:59:11 TH: those that can spawn new windows have that feature 12:59:18 Q+ 12:59:31 GJR author proposes, user disposes 12:59:50 SM: @target has different semantics in SVG? 13:00:35 Yam: against @target in 1.2 -- agree that natural that have in 1.1, but from practical POV it is a mess -- HTML5, XHTML2, etc. 13:00:50 SP: talking about 1.1 -- issue 1.1 as proper superset of basic 13:01:09 SM: if don't add anything to 1.1 can release as PER 13:01:12 with schema 13:01:21 SM: would not be superset of Basic 13:01:23 SP: why not 13:01:30 SM: not including @target 13:01:46 SM: those who care about input mode and @target will be affected - who are they? 13:02:02 Yam: don't care if 1.1 is superset or not 13:02:33 SM: very good point: explanation of XHTML family would be fine to support 1.1 second edition or first edition -- basic 1.1 document 13:02:59 SM: @target is single-most requested feature in our public wish list 13:03:21 TH: any UA used today that allows user not to open @target-ed windows 13:03:43 RM: a lot of users don't know that can click on link and open new window 13:04:55 TH: @target specifies UA behavior in practice 13:05:02 SP: a "hook" for use by 13:05:02 you're right, gregory 13:05:20 GJR: render unto User Agent what is user agent... 13:05:41 TH: going to be used to open new windows - removed to prevent that so shouldn't go back in 13:06:07 SP: didn't remove - never in STRICT and 1.1 is a revised version of STRICT, but didn't revise version of transitional DTD b/c nothing to revise 13:06:21 SP: one thing people have asked for is to use @target in 1.1 13:06:43 SP: not clear why we should say people shouldn't do that - perhaps should give arguments for people not opening windows 13:06:48 TH: why put back? 13:06:52 SP: popular demand 13:07:01 TH: what purpose does @target fill in XHTML? 13:07:34 people reintroduces it with dom injection... 13:07:38 TH: know complaints, but purpose aren't for frames mostly but for forcing open new windows 13:07:49 SP: XFrames - target a document onto a frame 13:08:13 SP: XFrames does NOT need @target - that's why need in HTML - if environment that needs this, here are the hooks you use 13:08:45 Alessio: @target should not be in 1.1 -- regard @target as action 13:08:58 SP: SVG uses @target, i believe -- trying to locate 13:09:41 Alessio: 2 diff roles for target - 1. to open new window; 2. to point at a frame in a frameset or multimedia concept 13:10:02 RM: if we don't have @target, what is effect? going to write scripts to force open scripts 13:10:19 RM: inhibitor to go to 1.1 or will just write script 13:10:36 TH: include despite bad practice because people going to do it anyway 13:11:01 GJR notes that BLOCKQUOTE deprecated for layout purposes in HTML4x but you can find it used for layout on W3C site 13:11:42 TH: why @target in HTML? to open new windows - compromise: use to target fragments that already exist - not to open new windows because that is not role of markup langauge 13:11:53 TH: say "is NOT to be used to open new windows" 13:11:59 "The target attribute is designed to be a general hook for binding to an external environment" 13:12:04 see http://www.w3.org/TR/2007/CR-xhtml-basic-20070713/#s_xhtmlmodules for explanation of Target Module 13:12:24 another use of "target" attribute: http://www.w3.org/TR/2005/REC-SMIL2-20050107/extended-linking.html 13:12:50 @target itself could be repurposed to a new tab, a sidebar by user agent 13:13:08 TH: user agent problem that persists - @target simply opens new window/browser instance 13:13:18 TH: why cave in to an illegitimate request? 13:13:30 SP: what is wrong with clicking on things to open windows 13:13:36 SM: explicit user action 13:13:43 GJR: that is point of UAAG1 and UAAG2 13:13:48 target in SMIL: "This attribute defines either the existing display environment in which the link should be opened (e.g., a SMIL region, an HTML frame or another named window), or triggers the creation of a new display environment with the given name. Its value is the identifier of the display environment. If no currently active display environment has this identifier, a new display environment is opened and assigned the identifier of the target." 13:13:55 TH: open in same window or another window 13:14:01 SP: programming problem with browser 13:14:09 TH: support a11y by suppressing @target 13:14:27 TH: take stand that every problem due to poor user agents 13:14:35 TH: opens unpleasant can of worms 13:14:48 SP: agree with removing features that have no raison d'etre 13:14:57 SP: open windows all day long by clicking on things 13:15:09 GJR: @target should be treated as an option, not an absolute 13:15:38 TH: if going to say has good uses, have to also note problems 13:15:58 SP: both cases UA problem 13:16:06 TH: in one case SHOULD in other SHOULD NOT 13:16:41 I don't think this argument is productive... If we don't like target (I am not a fan of target), we should discuss in XHTML Basic 1.1., not in XHTML 1.n 2nd edition... 13:17:21 @target should be treated as an option by UAs until explicit user action determines what to do 13:17:30 Whatever it is. XHTML 1.n 2nd ed should be a super set of XHTML Basic 1.1., which is the starting point of this discussion. 13:17:50 RM: applications in windows environment still open windows that are accessible 13:17:56 TH: don't agree 13:18:13 TH: far larger probability if opens in new window won't know 13:18:15 q+ 13:18:27 q+ 13:18:39 TH: authors shouldn't make assumptions 13:18:46 GJR: author proposes, user disposes 13:19:01 SP: opposite is never open another link in another window - non sequitor 13:19:03 maybe the UA could help, alerting when a new window is prospected 13:19:50 TH: problem include link and target to open in new window, have no idea what happens when link gets to user - author wants to open new window, user will be surprised by uncertainty and unexpected behavior 13:20:33 SP: filling in long form, don't understand something, click on help link, tells me what to do, but hasn't destroyed context of form and other helps open in same popup window 13:20:45 TH: if 800% magnification, where does window open? 13:20:58 target has an interoperability problem in mobile domain, certainly, but we have to accept @target for compromising SVG group... 13:21:13 there is a queue 13:21:39 AT should alert the user that new window being opened or new pane / tab being opened 13:21:52 TH: shou ld be user's choice, not authors 13:22:17 q- 13:23:26 q- 13:24:15 TH: screen magnifiers - simply blow up what is on screen - too dumb an app 13:24:32 GJR: if no @target will end up with raw javascripted links which are a WCAG violation 13:24:34 -Alessio 13:25:08 RM: not language purity - from author and/or user -- what do constituents want: authors creating material, and users interacting with that 13:25:37 RM: if in there could treat @target as an option - if have javascript won't have single standard hook 13:25:46 TH: to this point no UA has implemented that 13:26:16 TH: user agents include options to open new windows and tabs from context menues; not bothered to use @target to give users an option 13:26:25 +??P0 13:26:27 RM: will just use javascript to do anyway 13:26:31 zakim, ??P0 is Alessio 13:26:31 +Alessio; got it 13:26:56 q+ 13:27:14 q+ 13:27:15 The more things are forbidden, the more popular they become. -- Mark Twain 13:27:25 TH: why not restore MARQUEE 13:27:30 We have had no requests to put marquee back in 13:27:30 TH: same rationale 13:27:52 there is a queue 13:27:55