Re: [whatwg] hrefclass attribute ? -- semantics token reuse
Hello, On 11/27/05, ROBO Design [EMAIL PROTECTED] wrote: On Sun, 27 Nov 2005 00:28:49 +0200, Charles Iliya Krempeaux [EMAIL PROTECTED] wrote: Hello, This is kind of a follow up to a previous post of mine: rel/rev for form ? http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2005-November/005039.html http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2005-November/thread.html#5039 Now, although I still think rel and rev attributes on the form element would be useful, I did note (to myself) that in some cases rel and rev were not what I really wanted. rel and rev specify semantics between (all or part of) the document they are in and the resource the href (or action) attribute points to. (At least that's my understanding of it.) ... Hello! Best description of rel and rev attributes I ever read is: http://microformats.org/wiki/rel-faq Thanks. (I've already read it though.) ... For purposes of (semantic) token reuse, it would be nice if there was something like an hrefclass attribute. For example, let's say we had: ul class=shows lia/li lib/li lic/li /ul Now, lets say that instead of including this in our document, that we wanted to defer this to somewhere else. Then having something like the following would be very useful. a hrefclass=shows href=http://example.com/shows;.../a Now, it's true that with the class attribute by itself we could do something like: a class=href-shows href=http://example.com/contact;/a or: a class=refersto-shows href=http://example.com/contact;/a Shouldn't these last two links have href=http://example.com/shows;, like the first one? Is it a mistake or is it on purpose? Sorry, that was a mistake. They all should have been http://example.com/shows;. See ya -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/ ___ Never forget where you came from
Re: [whatwg] Menus, fallback, and backwards compatibility: ideas wanted
On Mon, 28 Nov 2005, Ian Bicking wrote: I think select isn't a very good basis for menus. Current (good) DHTML menus are richer than selects allow for, with things like nested menus. That can't be simulated with selects. Sure. As you point out, though, if the author is willing to do the leg work would probably be quite possible to take whatever markup we describe as being the menu markup and use it for DHTML menus. The reason I suggested that we should allow for easy fallback onto select is that for the menu-button use case, it's very easy to implement that kind of menu using select (and is done often today), and so it would allow for a seamless fallback (if we do it right). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Throbber response to XMLHTTPRequest() activity
anko wrote: Hi, It was suggested that someone email this list to see what you think about this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=312418. ... Currently XMLHTTPRequest does not change the throbbers state and it is hard to know if an AJAX enabled website is doing anything. That sounds like an implementation issue, I don't think the spec needs to address this at all. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Test suite: Embedded content
Simon Pieters wrote: Opera: If plugins are enabled, render all embeds and hide all noembeds, and parse noembed as CDATA. If plugins are disabled, hide all embeds and display all noembeds, and parse noembed as #PCDATA. Why does it need to parse it differently depending on the mode? Since noembed is just hidden anyway, it really shouldn't matter how its content is parsed and parsing it like #PCDATA makes the most sense. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Test suite: Embedded content
On Tue, 29 Nov 2005, Simon Pieters wrote: (object is less efficient to implement because the UA has to wait til it knows what the content type is before it can know how to render the element.) Also when there's a type attribute? The attribute is only a hint. So the hint is only for the UA to decide whether or not to load the resource? Well the hint allows the UA to prepare the right kind of rendering context, but the point is that it might be wrong, causing the UA to have to change rendering context, which is bad for perf. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] 1.2 scope
On Mon, 28 Nov 2005, Justin Kirby wrote: XUL is not proprietary. It is limited to a single implementation, but that does not mean it is exclusive. The word proprietary indicates that it is under exclusive control of an company. While this is true of Flash and Macromedia, it is not true of XUL and Mozilla. Sure it is. Microsoft couldn't come along and have equal say in the development of XUL, not like they could with the WHATWG or W3C specs. (Disclosure: I'm one of the editors of the woefully incomplete XUL spec.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Test suite: Embedded content
Blake Kaplan wrote: Lachlan Hunt wrote: Why does it need to parse it differently depending on the mode? Since noembed is just hidden anyway, it really shouldn't matter how its content is parsed and parsing it like #PCDATA makes the most sense. At least in Gecko, we parse the contents of noembed, noscript, noframes, and iframe as CDATA when we're not going to be using their contents because in the past, we've had lots of problems with authors treating these tags like C's preprocessor directives, handling cases like: headnoscriptbody.../noscriptscript.../scriptbody is extremely difficult (and then preserving round-tripping for editor gets to be a problem, and the list of problems goes on). Ok, but how is equivalent markup handled in XHTML, where parsing obviously can't switch to CDATA? -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Menus, fallback, and backwards compatibility: ideas wanted
Ian Hickson wrote: On Mon, 28 Nov 2005, Lachlan Hunt wrote: How about this, or some variation of: form ... menubar libutton type=submit for=foo name=menuFoo/button select id=foo name=foo ... /select /li ... /menubar /form Interesting idea. I like the non-JS fallback potential. Pity about the menubar being necessary to get the select to disappear, but I guess we need that... I originally just used menu, which is why the lis are there, but I'm not sure if its really is necessary. Couldn't the for attribute used to associate the button with the the select, be used to determine how to render the controls without the menu/menubar/etc. wrapper? It's unfortunate about the button being first, too. From an implementation perspective, is there any reason why it couldn't work with the order of the button and select elements swapped? At the moment, I thinking it should work if the button and select are just immediate siblings of each other in any order, though I'm not sure if it should work if there were other content in between. I guess we could change that if we say that in the new world in an li any selects are ignored and just the button is looked for... Hmm. I'm not sure I understand. Wouldn't that break many existing documents which do have select and buttons inside li elements? What if it were done like this: label button for=fooFoo/button select id=foo ... /select /label or label select id=foo ... /select button for=fooFoo/button /label In these cases, the button is acting as the label for the select menu which makes sense semantically and it probably wouldn't require any extraneous menu[bar] markup. There is, however, still the extra |for| attribute, but I think it (or something similar) is necessary so that we don't inadvertently break any existing documents that do have buttons and selects together in a label element. Alternatively, we could ditch the |for| attribute and substitute another element for label or, if possible, do as I suggested above and just use the |for| attribute to associate them regardless of their parent/ancestor elements. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Test suite: Embedded content
On Tue, 29 Nov 2005, Lachlan Hunt wrote: headnoscriptbody.../noscriptscript.../scriptbody Ok, but how is equivalent markup handled in XHTML, where parsing obviously can't switch to CDATA? It's a parse error (parse errors are fatal in XML). As to how the script problem is handled in X(HT)ML, this is something that is not well handled by XML UAs in general, and I'm not looking forward to defining how that works. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Test suite: Embedded content
Lachlan Hunt wrote: Why does it need to parse it differently depending on the mode? Since noembed is just hidden anyway, it really shouldn't matter how its content is parsed and parsing it like #PCDATA makes the most sense. At least in Gecko, we parse the contents of noembed, noscript, noframes, and iframe as CDATA when we're not going to be using their contents because in the past, we've had lots of problems with authors treating these tags like C's preprocessor directives, handling cases like: headnoscriptbody.../noscriptscript.../scriptbody is extremely difficult (and then preserving round-tripping for editor gets to be a problem, and the list of problems goes on). By treating the contents of these tags as CDATA, we're able to make most people happy (though nesting noscripts doesn't quite work as expected). -- Blake Kaplan
