Re: [whatwg] a href= ping=
J. Graham wrote: On Sat, 22 Oct 2005, Lachlan Hunt wrote: It could be defined in reverse, where the ping attribute (probably given a more suitable name, but I'll use ping for now) could be advisory information about the final destination and the href attribute defines the ping destination, such that following the href attribute would perform a redirect, but WA1 UAs could use the URI in the ping attribute to notify the user of the final destination (such as displaying it in the status bar). a href=scamsite.com ping=ebay.com a href=http://scamsite.com/;Ebay.com/a What's the difference? Sure it's not much in the face of an alert and savvy web user but there's a reason channging the status bar via js can be disabled (is it disabled by default?) Sure, scams are always a risk. It could be defined that if the location returned with the redirect does not match that in the ping attribute, that the user should be immediately notified of the deception. For legitimate cases, where the href is merely a redirection to the final destination, the user will get there without any problems. Also, the current draft of ping states: | When the ping attribute is present, user agents should clearly | indicate to the user that following the hyperlink will also cause | secondary requests to be sent in the background, possibly including | listing the actual target URIs. Perhaps the notification (whether in the status bar, tool tip or whatever) could state somthing like: ebay.com via scamsite.com Or maybe: scamsite.com, redirecting to ebay.com As long as it clearly indicates the intention in a way that also prevents its abuse by scammers. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] a href= ping=
Ian Hickson wrote: | Note: ... but authors are urged to use the ping attribute so that the | user agent can . Perhaps this sentence should be ended? :) Oops! Fixed. Not fixed very well. | ...so that the user agent can the user's experience. It's still missing the verb. You probably meant: | ...so that the user agent can [improve] the user's experience. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] a href= ping=
S. Mike Dierken wrote: I'm not sure where this idea has come from that sending POSTs is inherently unsafe (which, by the way, no-one has offered a good explanation for yet). POST requests are unsafe because the intent is to modify the data identified by the resource - data modification is tagged as being 'unsafe'. I think your confusing this with the fact that using GET requests for data modification is unsafe, and seem to be saying that POST is unsafe when used as intended!? -- Lachlan Hunt http://lachy.id.au/
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
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] Menus, fallback, and backwards compatibility: ideas wanted
Matthew Raymond wrote: Lachlan Hunt wrote: I don't believe my suggestion was altering the semantics of any element. The intention was the use the semantics of existing controls in a way that can rendered as a single widget that performs the functions of both (selection and submission) to achieve the submit-on-activation behaviour required, with a very good, accessible fallback mechanism in current UAs. You're changing the button so that when activated, it passes activation to an invisible select that is then presented as a menu. Then when you click on an option, the submit is triggered. It sure sounds to me like the semantics have been altered. Ok, I think I see where you're misunderstanding me, let me try to explain it a little better. Given this markup: cmd button name=menuFile/button select name=filemenu optionNew... optionOpen... optionSave... /select /cmd (This explanation also applies equally to intention of my previous markup suggestions in this thread) This could be rendered as a single widget using the button text as the menu label. In this sense, button is acting like the menulabel element and the select like a menu element (as currently described in the spec for navigatoinal menus), but provides better fallback for the command in legacy UAs and with script disaabled or unsupported. From a functionality perspective, you could look at it as though there is an implied command attribute on each option element referring to the button and upon selection, performs the button's default action. (We'd need to define how to handle cases where there's an explicity command attribute too) However, it isn't actually changing the semantics of either the select (selection) or the button (submission) element, it's merely changing the presentation and user interaction. Without a script that cancels the form submission, the result of activation in future WA1 UAs would be identical that of current UAs. i.e. The form is submitted. Similarly, this is another solution: | menulabel | menu | select | ... | /select | /menu | buttonFoo/button | /menulabel Again, what's the point of the menu element? And, the menulabel don't make sense. Dude, read the bleeping spec! From http://whatwg.org/specs/web-apps/current-work/#tutorial : I have and my question still stands. The menu element seems completely superfluous in that context. The point is we should try to reduce the amount of unnecessary markup, not just use it because the current draft uses it in a section that, if I've understood correctly, is being significantly rewritten. For situations where the button isn't used, you can just drop it: | menulabelFoo | menu | select | ... | /select | /menu | /menulabel Without the button, I think it should just be an ordinary select element. There would be no submission semantics (from the button) and, therefore, it doesn't really satisfy the semantics of a command menu. Well, I was thinking about it having the same semantics as when you hit enter when a control is selected. Is a submit button required in that case? Firefox doesn't seem to submit a form when pressing enter on a select control regardless of whether a submit button is present. I didn't bother testing other browsers. cmd select/ button/ /cmd Well, if you create an element specifically to encapsulate the select menu situation, I guess that's fine... (Other alternative element names for cmd could be: menuitem, commandmenu, cmdmenu, command, but I like cmd because it's short, easy to type and to remember.) Is this supposed to be a version of command with contents? No, command in the current spec represents an abstract form control for sharing features among several real form controls and my version of cmd doesn't. That could be confusing having similar names, perhaps command could be renamed to control or use an alternative name for cmd. If there's just one command menu, that (with an associated form element) should be all the markup requried for a functional menu with good fallback abilities. But, for the cases where it's more like a menu bar comprising several menus (e.g. File, Edit, View, etc.) they can be contained within a menu element: menu cmd/ cmd/ cmd/ /menu (where each cmd contains a select and a button, as above) Well, what I don't like about this scenario is that we end up with a lot of different markup in menu: | menu | a/ | cmd/ | command/ | li/ | menulabel/ | menu label=/ | /menu Is that really a problem? Besides, there's already a lot without cmd, it just adds one more. As for a stand-alone cmd elements being drop down menus, it mirrors what I've been trying to do with menulabel. Thoughts: * Merge command and menulabel. What? How are they in any way similar? * Merge cmd and menulabel. AIUI, the difference between them can
Re: [whatwg] Menus, fallback, and backwards compatibility: ideas wanted
Matthew Raymond wrote: Lachlan Hunt wrote: No, command in the current spec represents an abstract form control for sharing features among several real form controls. The command element is most certainly not a form control, since it can't be submitted I know that, I said *abstract* form control, though perhaps I should have omitted the word form. AIUI, the difference between them can be illustrated as follows: menu cmd !-- Menu command item -- button/!-- [Label] for command menu -- select/!-- The menu items -- /cmd li !-- Menu list item (e.g. navigational list) -- menulabel/ !-- Label for nav menu -- menu/ !-- The menu items -- /li /menu You're mistaken. The button caption actually isn't the menu label in many cases. Since the button itself wouldn't actually be visible in WA1 UAs, it's really only there for fallback, why can't it be used as the menu's label? You would only use the button for submission. Here's a stripped down version of what Ian has on his weblog: | form action=./ method=get | p | label | Jump to | select name=start/ | /label | input name=order value=-1 type=hidden | input name=count value=5 type=hidden | input value=Go type=submit | /p | /form Also, as you point out, the input element could be used instead. So you'd need either a label or child text, as you see Ian using above. Why? input type=submit is still a button, what difference does it make from the button element? But, if you really don't like overloading the use of the button as the menu label as well, then I guess we could add a label, but I think just using the button itself has the advantage of less markup and if the button isn't required to get the menu, authors won't bother including it, which reduces accessibility. | menulabel for=menu1Label Text/menulabel | menu id=menu1 | select/ | button/ | /menu We already have label for form controls, I don't think we need a new element for that especially when it's basically still associating a label with a form control. I also think you're overloading the use of the menu element too. Do you like the structure of any of these alternatives? (with the actual element names still up for discussion) 1. cmd buttonJump to/button select/ /cmd 2. cmd Jump to select/ buttonGo/button /cmd 3. cmd labelJump to select//label buttonGo/button /cmd 4. cmd label for=jumpJump to/label select id=jump/ buttonGo/button /cmd 5. cmd labelJump to select/ buttonGo/button/label /cmd 6. label cmdJump to select/ buttonGo/button/cmd /label 7. label for=jumpJump to/label cmd id=jump select/ buttonGo/button /cmd Hmm... Is there really a use case where we'd be using select elements for submenus? Not that I can think of, but select elements could have submenus using the optgroup element, as currently described in the spec. Not menus, mind you, but menus within menus. If not, then we could drop cmd from the list of possible children for menu while keeping the element itself. I don't understand your logic behind this. | menu | ... | command/ | /menu Why does command need to be a child of menu at all? It's really more of an abstraction, rather than a physical control for the user to use. Wouldn't it be better for them to be declared within the head or early within the body and then referenced by other controls as needed? -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Menus, fallback, and backwards compatibility: ideas wanted
Ian Hickson wrote: On Sat, 3 Dec 2005, Lachlan Hunt wrote: Earlier, Ian Hickson wrote: 1. Providing a menu bar for the entire window (or application, on Mac)... I just had a thought that maybe this could be marked up by including the menu within the head element... However, this would only be possible in XHTML documents. Yeah, in HTML it would force the body to open. An option for XHTML, indeed. It could still be done in HTML by modifying the DOM to move it from the body to the head using a script. UAs without script would just get a regular menu within the page, which isn't bad fallback. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Menus, fallback, and backwards compatibility: ideas wanted
Ian Hickson wrote: On Wed, 7 Dec 2005, Matthew Raymond wrote: menu option label=1/ option label=2/ option label=3/ /menu I don't really want to add a lot of new attributes to option; What new attributes are you talking about? Option already has a label attribute in HTML4. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Menus, fallback, and backwards compatibility: ideas wanted
Nate H. wrote: I'm guessing nesting a select within another select will break current UAs. Sub-menus like that will be handled with nested optgroup elements. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Menus, fallback, and backwards compatibility: ideas wanted
Ian Hickson wrote: How about: form action=redirect.cgi menu type=commands menu label=Select site... select name=goto onchange=if (this.options[this.selectedIndex].value) location = this.options[this.selectedIndex].value option value= selected=selected Select site: /option option value=http://www.apple.com/; Apple /option option value=http://www.mozilla.org/; Mozilla /option option value=http://www.opera.com/; Opera /option /select spaninput type=submit value=Go/span /menu /menu /form Ignoring this abuse of select as a navigational menu which would be better handled with a href, that handles the following cases fine: * Legacy UAs, with script * Legacy UAs, without script * New UAs, with script But, because the button will be hidden, it doesn't handle new UAs, without script. They'll only be able to select the menu item, but nothing will happen. The original idea I posted in this thread was that selecting an option would implicitly activate the associated submit button and that scripts (if supported) could capture the onsubmit event and deal with it appropriately. The idea is somewhat like having an implied command attribute on the option elements pointing to the submit button. The outer menu makes the toolbar, the inner menu is a drop-down button on that toolbar. That's fine, I like it better than using a new menubar element. The span/span hides the input from the menu. The value= hides that option from the menu. What semantics does the span have in this case to make it do that? I think an attribute on the button that says this is the default action to be performed when a menu item is selected and that it should not be rendered by default would be better. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Menus, fallback, and backwards compatibility: ideas wanted
Ian Hickson wrote: On Wed, 14 Dec 2005, Sander Tekelenburg wrote: But then still, until they all do, authors will have to continue providing in-body navigational content. One of the key concepts Tantek often pushes in the microformats forums is the idea that metadata should be visible. link violates this concept in most UAs today. I think that's why it hasn't really taken off. Link was never intended to be invisible metadata, it's just that UAs never really implemented them beyond linking to stylesheets, and those that did (Mozilla Suite, Opera and Lynx), didn't to anything very creative with them. I think the fact that a supports rel= gives us a way to drop link altogether, actually. What about link rel=stylesheet? I don't expect a rel=stylesheet to perform the same function. style@import;/style could have been an acceptable alternative to link if IE didn't have annoying bugs with it. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] CENTER, MENU, DIR, NL
Matthew Paul Thomas wrote: Either div is going to be in HTML 5 but has yet to be specified (like object), or it's not going to be in HTML 5 but is incorrectly used in some examples. If the latter, that will make certain the semantic-free fates of section and p. AIUI, HTML 5 will inherit everything from HTML 4 Strict, except for some selected presentational elements/attributes and, I suspect, the few attributes that are widely unsupported (e.g. char and charoff for table cells). Div is required, there is sometimes no other alternative. It's not presentational, though it's not particularly semantic either and unless it's used with semantic attribues like lang and dir, it's purely structural. But the semantics available with the other elements can't possibly cover every possible use case and div is sometimes the only choice without resorting to abusing another semantic element. Although, such cases will be reduced significantly now that we have the various sectioning elements. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] comment parsing
Ian Hickson wrote: Imagine that the page contains the following: ... !-- script hostileScript(): /script -- ... ...where hostileScript() is some script that does something bad. A DOS attack on the server could cause the transmitted text to be: ... !-- script hostileScript(): /script ...which, if we re-parse the content upon hitting EOF with an open comment, would cause the script to be executed. I don't understand these security concerns. How is reparsing it after reaching EOF any different from someone writing exactly the same script without opening a comment before it? Won't the script be executed in exactly the same way in both cases? However, don't take this as support for choosing to reparse it, I don't like the concept of doing that at all for other reasons, I just don't understand this security concern. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Comment Syntax and Parsing
Ian Hickson wrote: On Mon, 23 Jan 2006, Lachlan Hunt wrote: Well, for what it's worth, I still don't think you were being stupid, I think you were right all along and had this been implemented by more than just Mozilla 7 years ago, the result may have been different. Authors find the -- thing unbelievably confusing. Oh, yes, absolutely. I know, I've tried explaining it to some with varying degrees of success. Why does: !-- Hello -- World -- How does comment work? -- I don't know. -- Do you? -- ...work, Well that depends on the implementation and how SGML defines that such erroneous comments be handled. (Without a copy of IS0O-8879 handy, it's difficult to check, so the following is based purely on observing the implementations.) Mozilla will handle that entirely as a single comment, which is closed at the occurance of -- at the end. onsgmls, however, (which is more likely to be closer to the SGML spec) will encounter the 'W' in 'World', which is outside of the comment, treat it as an erroneous unclosed comment declaration and implicity close it. It will then drop the 'W' completely and continue on, treating comment as an unknown and unclosed element along the way (assuming an HTML doctype is used). So, basically, none of those examples actually work, they just appear to work in some implementations. (What HTML5 says isn't really quirks mode comment parsing, it's even simpler.) Ok, well then I don't have a clue how quirks mode parsing works, it's just too unpredictable. I'm glad this is going to be simpler. Do you know if browsers will be using this for both standards and quirks mode or will they retain their existing quirks mode parsing and use this as the new standards mode parsing only? Probably the same as XML. Or maybe just !-- followed by zero or more characters other than U+, followed by --. I vote for keeping it very similar to XML, it'll be easier for authors only having to learn and remember one comment syntax. Plus CSS's. Plus Javascript's. So three syntaxes, at least. Yes, but authors don't confuse CSS and JavaScript as being the same language as HTML as often as they confuse HTML and XHTML as being the same. ...and this is assuming they'll ever use XML. Well, many authors believe their using XHTML, and many even believe they using the correct XHTML MIME Type (using meta), even though they're not. So, regardless of whether they actually are or not, they're going to believe they are and it's best not to confuse them more by saying: ! isn't well-formed XML and have them come back and say: the validator says it's fine and then tell them: that's because the document isn't XHTML. only to hear: Yes it is, look at the meta element and all these slashes (br/) Another question is, do we wish to continue allowing white space like this: !-- comment -- I believe it's supported by all browsers without any difficulty Actually, it isn't. In most browsers that I tested the above gets treated as an unclosed comment which is then re-parsed in close at first mode. You're right, but IE was the only browser that I could find which (in standards mode) treated it like that. Since we're dropping the re-parse mode (see earlier mails), this goes away with it. OK. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Sandboxing scripts: call for a wider discussion
Alexey Feldgendler wrote: AFAIK, document.write is not standardized anywhere at all (am I right?) http://www.w3.org/TR/2001/WD-DOM-Level-2-HTML-20011210/html.html#ID-75233634 -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Comment Syntax and Parsing
Ian Hickson wrote: On Tue, 24 Jan 2006, Lachlan Hunt wrote: PA!- !--SS -- | - ! | PASS -- Comment should be - !-- IMHO. It's still a bogus comment (in HTML5 nomenclature), the -- part is irrelevant. Ok, so if a comment only starts with '!' then it ends at the first '' only (ignoring any '--'), but if a comment starts with '!--' then it must end with '--'. PA!- --SS| - | PASS PA!- -- SS | - | PASS These are bogus comments, so again, they should be - -- and - -- respectively, IMHO. Ok. PA!-- FAIL -- SS | FAIL| PASS Disagree. The terminator should be --, not -- S* . I don't see any good reason to have -- S* . I was working on the assumption that the comment would end at the first occurance of '' while in the comment end state, but that whitespace would be ignored while searching for it. Several browsers already handle it like that including Mozilla, Opera and Safari (except in Opera, the comment contained FAIL -). Although IE, OmniWeb and iCab failed. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Comment Syntax and Parsing
Ian Hickson wrote: On Wed, 25 Jan 2006, Lachlan Hunt wrote: Ian Hickson wrote: On Tue, 24 Jan 2006, Lachlan Hunt wrote: PA!-- FAIL -- SS | FAIL| PASS Disagree. The terminator should be --, not -- S* . I don't see any good reason to have -- S* . I was working on the assumption that the comment would end at the first occurance of '' while in the comment end state, but that whitespace would be ignored while searching for it. Several browsers already handle it like that including Mozilla, Opera and Safari (except in Opera, the comment contained FAIL -). Although IE, OmniWeb and iCab failed. Really? In my testing, browsers didn't reliably do this. Were you testing standards mode or quirks mode? Did you have the potential to be hitting unexpected-EOF-reparse behaviour, or was it definitely the first-parse behaviour? I tested the following in the live dom viewer using Firefox 1.5.0.1 Win and Mac, Opera 8.5/Mac, Opera 9 Win and Mac, Safari 2.0.3, IE6, OmniWeb 5.1.2 and iCab 3.0.1. !DOCTYPE html PA!-- FAIL -- SS Browser | Comment | Rendered --|-|--- Firefox | FAIL | PASS O 8.5/Mac | FAIL - | PASS O 9.0/Mac | FAIL | PASS O 9.0/Win | FAIL | PASS Safari| (not shown) | PASS IE6 | (not shown) | PA FAIL -- SS iCab | (not shown) | PA FAIL -- SS OmniWeb | (not shown) | PA FAIL -- SS (The live dom viewer didn't work for OmniWeb, I just used an HTML file instead) -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Comment Syntax and Parsing
Ian Hickson wrote: On Wed, 25 Jan 2006, Lachlan Hunt wrote: I tested the following in the live dom viewer using Firefox 1.5.0.1 Win and Mac, Opera 8.5/Mac, Opera 9 Win and Mac, Safari 2.0.3, IE6, OmniWeb 5.1.2 and iCab 3.0.1. !DOCTYPE html PA!-- FAIL -- SS This triggers SGML comment parsing mode (which you don't want to be testing) in a number of browsers. Why? The closer we can define the behaviour to be compatible with existing standards mode behaviours, the better it will be for backwards compatibility? -- Lachlan Hunt http://lachy.id.au/
[whatwg] Tag Soup: Blocks-in-inlines
Hi, This is in response to Hixie's article [1]. I fully agree that the both IE's incestual approach and Opera's genetic inheritance problem (though a well-formed tree) are out of the question. I like the Hiesenburg theory in some cases, although its lack of easy predictability is a big downfall. Safari's adoption-agency method is reasonable, although we'd need to find a way to avoid the Hindenburg disaster when the child is kidnapped during birth. However, there may be a 5th option available. Consider this, using the following markup samples from the article. 1. empX/emY/p BODY + P + EM + #text: X + #text: Y The theory is that any inline elements started and not ended before a block element will immediately become a child of the block element, regardless of where the end tag for the inline element occurs. This avoids the Heisenburg uncertainty principle employed by Mozilla. 2. empXY/p/em BODY + P + EM + #text: X + #text: Y In this case, Mozilla would have had the em and p elements swapped (just like if this were a well formed XHTML document), but that requires some pre-parsing which I imagine would be a pain for incremental rendering. 3. empX/ppY/p/em BODY + P + EM + #text: X + P + EM + #text: Y This is exactly the same as the last one, except there were two block level elements within the inline element, and as such, the inline element was cloned and each parent was given custody of one, which nicely avoids the time consuming and painful child custody hearings. 4. emXpY/emZ/p BODY + EM + #text: X + P + EM + #text: Y + #text: Z This is almost the same as the first example, except that there is a text node within the em element which is not a child of the p element. So, again the em element is cloned. The first becomes a parent of X, the second becomes the parent of Y, the child of P and the brother of Z. I believe all of these trees meet the requirements of coherence with regards to the DOM, transparency with regards to CSS and, most certainly, predictability. It also seems perfectly backwards compatible with the rendering achieved in all browsers, but with a much saner DOM under the hood. [1] http://ln.hixie.ch/?start=1138169545count=1 -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Tag Soup: Blocks-in-inlines
Billy Wong wrote: On 1/25/06, Lachlan Hunt [EMAIL PROTECTED] wrote: I'm not saying it won't break anything, but every single change we make to the parsing could possibly break any number of the billions of pages on the web in any number of browsers. But using your method (swapping inline node and block node) would break presently valid and correct webpages. Such pages are invalid because inline-level elements are not allowed to contain block-level elements. HTML pages containing the following: span div.../div /span could be considered well-formed (if you apply the concept of well-formedness to HTML, even though it's not formally defined for it), but it's certainly not valid according to any official DTD. If breaking things is unavoidable, I prefer breaking things which are written incorrectly. No-one is intending to break anything that is written correctly. My idea is very extreme but simple and effecient: Parse the page regardless of what between / . See what's written inside the close-tag merely a visual clue. Example: spandivX/spanY/div + span + div + #text: X + #text: Y I'm kind of confused by what you're trying to do there. You seem to be implicitly closing the div immediately before the span. But then the Y doesn't seem to be a child of the span at all in the markup, it looks like it should be a child of the div, yet in your DOM, it's not a child of the div, but is of the span. The DOM look equivalent to this markup: spandivX/divY/span which is insane. It would make a little more sense if it were like this: + span + div + #text: X + #text: Y In other words, it would be equivlant to this markup: spandivX/div/spanY That is actually quite sane and is what OpenSP does with invalid HTML,. regardless of which elements are used (presumably according to some SGML rules), but it would not be compatible with the current state of the web at all, and so is not a real option. To correctly written webpages, this should pose no problems. To incorrect webpages, they deserve it since the point they ask the UA to use standard mode. In theory, that sounds nice, but you have to remember: to a rough approximation, all the content on the Web is errorneous, invalid, or non-conformant. -- Hixie So, to say they deserve it to 100% of the web (roughly speaking) isn't really an option, unfortunately. It's ok to say it to the most pathological of cases that depend on one particular browser's insane and undefined error recovery techniques, yet already breaks in everything else, but not to the whole web. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Tag Soup: Blocks-in-inlines
Simon Pieters wrote: Hi, From: Lachlan Hunt [EMAIL PROTECTED] However, there may be a 5th option available. Consider this, using the following markup samples from the article. 1. empX/emY/p BODY + P + EM + #text: X + #text: Y Why would you drop the first EM? Why should this be parsed any different than 4? I think it should look like this instead: Because there were no text nodes between the em start-tag and the p start tag, so putting it in there would be completely redundant and useless. Although putting it there will have no detrimental effect beyond wasting a minuscule amount of memory, so it really doesn't matter. 2. empXY/p/em BODY + P + EM + #text: X + #text: Y Why are there two text nodes? Copy paste error. I don't think there's much advantage of differentiating between well-formed and malformed markup. They should be parsed the same to keep things simple and predictable. Thus, empXY/p/em should be parsed as: BODY + EM + P + EM + #text: XY ...IMHO. Agree; but again, the empty EM element is redundant. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Tag Soup: Blocks-in-inlines
Alexey Feldgendler wrote: On Thu, 26 Jan 2006 21:09:44 +0600, Anne van Kesteren [EMAIL PROTECTED] wrote: em has never been defined in a way that it could give entire paragraphs emphasis. I'm not really saying anything is wrong about it, just that has never been defined. Also, em was defined to be inline-level (nothing to do with presentation) in HTML4 which means that it could not contain block-level (again, apart from presentation) elements so parsers did funny things on error recovery. This confirms the point that the classification of elements into block-level and inline-level is just a convention not backed by a semantic requirement. The debate about the block vs. inline distinction is, unfortunately, not quite so simple. It's been discussed a few times on www-html in the past. I wrote a fairly good overview of the arguments in December 2003 [1] and then the issue came up again in July 2004 [2] [1] http://www.w3.org/mid/[EMAIL PROTECTED] [2] http://www.w3.org/mid/[EMAIL PROTECTED] -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Adoption Agency Algorithm
Ian Hickson wrote: On Sat, 28 Jan 2006, Lachlan Hunt wrote: Why can't it just be defined that noframes and noscript content gets parsed exactly as regular markup Because there are a _lot_ of side-effects of parsing as regular markup. e.g. noframes style.../style i Foo /noframes Bar ...the Bar musn't be in italics, the style block musn't be used, etc. There's really a LOT of things to catch. In a frameset document, where all the content is displayed within frames using external documents, when would Bar ever be displayed anyway (unless the UA doesn't support frames and was rendering the noframes content). In which case, why does it matter whether or not Bar ends up within the I element or not? It should be treated exactly the same way as this would be for a non-frameset document: body iFoo /body Bar Besides, if that was a real problem, could it not be defined as a special case so that upon encountering /noframes, all unclosed child elements are then closed and not reopened? I'm not sure what the style element in your example is supposed to show, but I'm sure it could be ignored just like scripts, although it would have no effect on the documents within the frames anyway. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Parsing: Tokenisation - DOCTYPE State
Simon Pieters wrote: Hi, From: Lachlan Hunt [EMAIL PROTECTED] As far as I can tell both of these DOCTYPEs are considered conformant, but shouldn't the first be an easy parse error? !DOCTYPEhtml !DOCTYPE html Why? Both trigger standards mode as far as I can tell. :-) It did in the browsers I tested too, but that doesn't mean it works for all of them. It just seems wrong to omit the space, but if Ian intentionally allowed it, then that's fine. * Why is it marked as being error at that stage? It doesn't seem to be necessary because of the last step in the DOCTYPE name state that says: [...] You might not get to the doctype name state. (Consider !DOCTYPE.) Then the '' would get seen in the DOCTYPE state: U+003E GREATER-THAN SIGN () Easy parse error. Emit a DOCTYPE token whose name is the empty string and that is marked as being in error. Switch to the data state. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Update to the Adoption Agency Algorithm
Blanchard, Todd wrote: Lachlan Hunt wrote: Blanchard, Todd wrote: What I want to know is: if the cloned node has an id attribute, and id is meant to be unique, then how do we resolve this conflict? The ID attributes need to be duplicated in such cases, that's what existing browsers do. OK, I have to disagree with this - the id's MUST NOT be duplicated as the end result is simply converting one kind of error to a different kind of error. I'd also suggest that browsers should be NOISY about bad HTML such that authors are encouraged to fix it (possibly through some disable-able preference). There are extensions available, such as the HTML tidy extension for Firefox, which *will* alert the user of such mistakes. There are also various tools available for browsers, such as the JavaScript console, Venkman, the DOM inspector and many more that the author can make use of to diagnose problems. I don't agree that anything should be added as a hidden pref for this, that would just add bloat to the software the most users won't need and provide nothing that existing tools don't already. As it is now, site authors spend a great deal of time scratching their heads trying to make sense of why things are acting oddly Errors caused by the result of duplicate IDs either in the markup or indirectly as a result of badly nested elements can be fixed by a quick visit to the validator (or other conformance tool) or by making use of any or all of those tools I mentioned above. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Update to the Adoption Agency Algorithm
Gervase Markham wrote: Lachlan Hunt wrote: Errors caused by the result of duplicate IDs either in the markup or indirectly as a result of badly nested elements can be fixed by a quick visit to the validator (or other conformance tool) or by making use of any or all of those tools I mentioned above. It's much harder to spot them when they are dynamically generated by e.g. a cloneNode operation. You can't submit your browser's DOM tree to the validator... Any markup that causes a browser to automatically clone a node will be non-conformant and will be flagged as erroneous by a validator. Of course it won't say duplicate ID, but it will give errors about badly nested elements. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] getElementsByClassName()
Ric Hardacre wrote:
Gervase Markham wrote:
If you have:
p class=foo barFred/p
p class=bar fooBarney/p
p class=foo baz barWilma/p
which should be picked up by getElementsByClassName(foo bar)?
this also raises the possibility of some confusion as the order of
inheritance is important:
foo
{
color: red;
}
bar
{
color: blue;
}
in the quoted example Fred and Wilma would be blue and barney red.
According to which rules specified in CSS will that be the case? Given
that CSS (assuming you meant to use class selectors instead), all three
markup samples will be blue. The order of the class names in the markup
is irrelevant. The order of the rules specified in the CSS is relevant
and the latter rule of equal specificity takes precedence.
--
Lachlan Hunt
http://lachy.id.au/
Re: [whatwg] Update to the Adoption Agency Algorithm
Blanchard, Todd wrote: Any markup that causes a browser to automatically clone a node will be non-conformant and will be flagged as erroneous by a validator. You are assuming that validators run javascript - they generally don't. I'm well aware that validators don't run JavaScript and I'm talking about a case where they don't even need to. Given this markup that will cause a node to be cloned by the Adoption Agency Algorithm: em id=xpfoo/embar/p The validator *will* flag that as an error and, according to the algorithm, it will also cause duplicate IDs, which is what we were discussing. The only case that won't happen is if that markup is written as a result of document.write() or innerHTML. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] getElementsByClassName()
Jim Ley wrote:
On 2/3/06, Michel Fortin [EMAIL PROTECTED] wrote:
Le 2006-02-03 à 09:30, Jim Ley a écrit :
So to generalize the use case, when I want to attach an event to a
child element or an element linked by any other mean to the element
having that class, I can't use addEventListenerToClass.
So this shows that addEventListenerToCSSSelector is really what you
want so you can attach it to A's that are children of the class
doesn't it?
I don't agree with that, there are many valid use cases for a
getElementsByClassName and while it is true that many of them are event
related, that doesn't mean they all are. For example, if an author
marked up dates in their document like this (due to the lack of a date
element)
span class=date2006-02-03T01:30Z/date
A script could get all the elements with the class name of date, parse
it and modify it to the user's preferred time zone and format. So, for
example, the script could change it to this for a typical Australian user:
span class=date03 Feb 2006 12:30 (local time)/span
Whereas, an American user may get this instead:
span class=dateFeb 02, 2006 20:30 (local time)/span
Regarding the idea for addEventListenerToSelector, while I don't think
it should be implemented as a function like that, the idea of attaching
events based on a selector is quite reasonable. What if there was a way
to declaratively attach events to elements in the same way that the
on[event] attributes in HTML do, but with same level of abstraction
provided by CSS using selectors. It could even be used for some the
event-related use cases for getElementsByClassName, simply by using a
class selector.
Of course, there is XML Events, which also seems to be declarative, but
from what I know about it (not very much), it seems to be limited to
specifying IDs of the target/observer elements and putting IDs on every
target element is not always convenient; or otherwise embedding the
event attributes (like ev:handler, ev:event, etc) throughout the markup,
just like with the HTML on[event] attributes.
There's also IE's behaviours using HTCs and the proprietary 'behavior'
property in CSS, but it seems rather complex and HTCs look quite messy
(they seem to be a weird mixture of proprietary HTML with some XML
syntax), although perhaps they were on the right track with the concept
of making them declarative.
For example, using this CSS-like syntax (but it's not CSS).
selector {
event-name: function();
}
For example, using a real (rather nifty) javascript example, called Lightbox
http://www.huddletogether.com/projects/lightbox/
The basic way in which this works is to look for A elements with a rel
attribute containing a lightbox value. For everyone it finds, it
attaches a click event handler, which then handles all the funky
animation and loading of the image within the same page.
Using the above css-like syntax, that could be achieved by doing this:
a[rel=lightbox] {
click: showLightbox(attr(href), attr(title));
}
I know it's not an extremely well thought out idea, it's just a bit of
brainstorming, but it could always be improved. It also seems to be a
little out of scope for the WhatWG.
--
Lachlan Hunt
http://lachy.id.au/
Re: [whatwg] getElementsByClassName()
Lachlan Hunt wrote:
For example, using this CSS-like syntax (but it's not CSS).
selector {
event-name: function();
}
I just remembered BECSS, which is pretty much that exact thing. Strange
how didn't occur to me at all, though it must have been buried in my
subconscious somewhere :-).
http://www.w3.org/TR/becss
--
Lachlan Hunt
http://lachy.id.au/
Re: [whatwg] getElementsByClassName()
James Graham wrote: Also I would be surprised if there weren't multiple implementations of getElementsByClassname floating around in javascript libraries. So you can't really call it unimplemented. While there are many JavaScript implementations (I even wrote one myself a few months ago), all the custom JS implementations count for exactly zero native implementations in UAs, which is what really counts. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Targetting different anchors after submitting the form
Mikko Rantalainen wrote: Currently it's possible to do stuff like this form action=url#anchor input name=foo type=submit input name=bar type=submit /form and the UA scrolls down to element with id anchor on the page returned by the server. It would be nice to be able to set target anchor on per-submit-button basis. Perhaps something along the lines form action=url input name=foo type=submit anchor=xfoo input name=bar type=submit anchor=xbar /form would result to action urls url#xfoo and url#xbar respectively. You could get the server to send a 303 See Other response and set Location: http://example.com/url#foo. RFC 2616: 303 See Other The response to the request can be found under a different URI and SHOULD be retrieved using a GET method on that resource. This method exists primarily to allow the output of a POST-activated script to redirect the user agent to a selected resource. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Internal character encoding declaration
Henri Sivonen wrote: If a meta element whose http-equiv attribute has the value Content-Type (compare case-insensitively) and whose content attribute has a value that begins with text/html; charset=, the string in the content attribute following the start text/html; charset= is taken, white space removed from the sides and considered the tentative encoding name. This will need to handle common mistakes such as the following: meta ... content=application/xhtml+xml;charset=X meta ... content=foo/bar;charset=X meta ... content=foo/bar;charset='X' meta ... content=charset=X meta ... charset=X I'm not sure which browsers support each one, they'll all need to be tested. Authors are adviced not to use the UTF-32 encoding or legacy encodings. (Note: I think UTF-32 on the Web is harmful and utterly pointless, I agree about it being pointless, but why is it considered harmful? I'd like to have some text in the spec that justifies whining about legacy encodings. What are your reasons for whining about legacy encodings and what would you like the spec to say? Also, the spec should probably give guidance on what encodings need to be supported. That set should include at least UTF-8, US-ASCII, ISO-8859-1 and Windows-1252. And probably UTF-16 as well. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] JSONRequest
Gervase Markham wrote: Douglas Crockford wrote: The JSONRequest does only one thing: snip Are you planning to take the excellent advice from I forget who to change the name? That was me. Nice to see I'm quite memorable :-) The name XmlHttpRequest sucks because it doesn't necessarily return XML, and it doesn't have to be over HTTP. I agree, but considering we're stuck with it... Why not just call it Request, Why not just reuse XMLHttpRequest? and have an API to set the Accept: header, XHR already does. var r = new XMLHttpRequest(); r.open(post, http://example.org/json;) r.setRequestHeader(Accept, application/json); r.setRequestHeader(Content-Type, application/json) r.send(jsonData); To make XMLHttp as secure as JSONRequest claims to be (assuming for the moment that the proposal can be made completely secure), we would just need to find a way to tell the UA to allow cross domain access for XHR under certain conditions by meeting the criteria in Security section of the JSONRequest proposal. e.g. Don't send cookies, usernames, passwords, etc., prevent access to detailed error messages from other domains, help prevent DoS attacks to other domains using random delays between requests and address any other security concerns raised. That way, if the conditions are met by both the script and server, the UA could allow access to the response, otherwise treat it as an XSS attack of some sort and deny it. -- Lachlan Hunt http://lachy.id.au/
[whatwg] basefont
Hi, I'm just wondering how you're intending to deal with basefont? AFAIK, the only browser that supports it these days is IE, but it does so by breaking the DOM (I could be mistaken, but I think NN4 supported it too). Considering that no other modern browser supports it and that IE's DOM looks like this when base font is used: !DOCTYPE html titletest/title pbasefont face=Arial size=3test/p #comment: CTYPE ht HTML HEAD TITLE BASEFONT face=Arial BODY P #text: test BODY (shown as error) I think it should be made officially obsolete. It should be inserted into the DOM as an empty element, but UAs should ignore it. UAs may choose to support it at their own risk, but must not do so by breaking the DOM like IE does. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] A better name than gauge for the element that shows a measurement
Ian Hickson wrote: So one of the HTML5 elements is gauge: Relevancy: gauge70%/gauge Unfortunately, the study Google did on Web authors showed that authors cannot spell the word language, and I see no reason to believe that they might spell gauge either. But unlike the almost entirely useless language attribute, gauge will actually have a noticeable result in future browsers and so if it's typed incorrectly, the author would not see the result and, hopefully, go and fix it. Whereas if they mistype language, they won't notice the error until they validate. meter -- looks odd when taken out of context But metre is the correct spelling in en-AU and en-GB, and so I think much of the world outside of the US may misspell it. I'd prefer to find a word without spelling differences between countries, if possible. Although I guess, just like 'color' and 'colour', authors could get used to it. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] JSONRequest
Douglas Crockford wrote: If application/json isn't acceptable (though I don't know why it wouldn't be), then try a hyphen instead: application/json-request The issue is to provide a way of identifying JSONRequest transactions that cannot be confused with legacy applications. To me, this just feels like misuse of the MIME type. It should describe the content type of the message body, not the protocol/method used to access it. Maybe a parameter could be used instead. i.e. application/json;param=value Though, as I'm still not exactly sure what the new MIME type idea is supposed to express, I've got no idea what the parameter could be called. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] JSONRequest
Gervase Markham wrote:
Douglas Crockford wrote:
I have modified the JSONRequest proposal so that the Content-Type in
both directions must be application/json/request.
Er, why? Having two slashes in a content type is either extremely weird
or completely illegal (glancing at the RFC, I'm not certain which).
http://www.mhonarc.org/~ehood/MIME/2046/rfc2046.html
RFC 2616 states:
media-type = type / subtype *( ; parameter )
type = token
subtype= token
token = 1*any CHAR except CTLs or separators
separators = ( | ) | | | @
| , | ; | : | \ |
| / | [ | ] | ? | =
| { | } | SP | HT
And RFC 2045 says something very similar. So the second '/' is indeed
illegal.
If application/json isn't acceptable (though I don't know why it
wouldn't be), then try a hyphen instead: application/json-request
--
Lachlan Hunt
http://lachy.id.au/
Re: [whatwg] image captions
Ian Hickson wrote: On Tue, 4 Apr 2006, fantasai wrote: I'm wondering what WA1 considers appropriate markup for a figure with a caption. pimg src=image-equivalent-of-text alt=text title=caption/p That's fairly limited because it doesn't allow markup within the title attribute. What about extending the caption element, currently used with table, to img, object and embed? -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Handling of script elements inside rendered OBJECT
Shadow2531 wrote:
object type=text/html data=about:blank
scriptalert('You should not see this!');/script
/object
What should happen in situations like that?
The script element is alternate content.
The object is rendered.
The script SHOULD NOT be executed *until* the alernate content is
rendered.
If scripts inside object aren't executed, then consider what should
happen with this:
script
document.write(object type=\text/html\ data=\test\);
/script
palternate content for when both scripts and the object isn't
supported/p
script
document.write(\/object);
/script
Because of the way document.write() works by writing data back into the
stream, the question is: if scripts inside objects are not executed, is
the second script considered part of the alternate content and thus not
executed?
With scripts being executed, that ends up being the following
This is the innerHTML representation from Firefox:
!DOCTYPE HTMLhtmlhead/headbody
script
document.write(object type=\text/html\ data=\./\);
/scriptobject type=text/html data=./
palternate content for when both scripts and the object isn't
supported/p
script
document.write(\/object);
/script/object
ptest/p/body/html
This is the DOM representation of the same:
DOCTYPE: html
HTML
HEAD
BODY
SCRIPT
# #text: document.write(object type=\text/html\ data=\./\);
OBJECT data=./ type=text/html
P
#text: alternate content for when both scripts and the object
isn't supported
SCRIPT
#text: document.write(\/object);
P
#text: test
If, however, scripts aren't executed inside the second script would not
be executed and thus the /object would not be written out. That would
mean the rest of the entire document would end up being inside the
object, as can seen in the output from IE
#comment: CTYPE ht
HTML
HEAD
TITLE
BODY
SCRIPT
OBJECT type=text/html data=./
(child nodes weren't output by IE)
The innerHTML representation:
!DOCTYPE HTMLhtmlHEAD/HEAD
BODY
SCRIPT
document.write(object type=\text/html\ data=\./\);
/SCRIPT
OBJECT type=text/html data=./
palternate content for when both scripts and the object isn't
supported/p
script
document.write(\/object);/scriptptest/OBJECT/BODY/html
--
Lachlan Hunt
http://lachy.id.au/
Re: [whatwg] Intergrating the DOM and JavaScript (JSDOM)
Dean Edwards wrote: It would be great if NodeLists were subclasses of JavaScript Array objects (especially with the introduction of Mozilla's Array Extras [1]). This makes iteration over DOM queries more flexible. It sounds like a nice idea, but there are some problems with it that I can see. NodeLists are live, meaning that changes made to the underlying DOM will be reflected in the list. Conversely, it means that any changes made to the NodeList would logically need to be reflected in the DOM. e.g. If you get a node list of P elements like this var pNodes = document.getElementsByTagName(p); then later in the script you remove one of those P elements from the DOM, it will also be removed from that NodeList. This is a problem for your idea because it means that changes made to the NodeList would also need to be made to the DOM, in order to keep them in sync. e.g. What would happen if you used the Array push() function on the NodeList? pNodes.push(newNode); Where in the DOM would that new node be added? -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Handling of script elements inside rendered OBJECT
Shadow2531 wrote: That problem could be avoided by authors making sure each document.write() wrote complete element markup instead of splitting it up like in your example. The problem could be avoided by not using document.write() at all, but in reality that's not going to happen any time soon. not executing scripts in object tags would break lots of things. Ouch. Possibly, but it depends how you look at the situation. Considering the behaviour of Firefox and IE are the complete opposite, and that IE actually doesn't execute scripts, then it's unlikely to break many things. This also means that it is unlikely that many authors are depending on it being one way or the other. This actually gives the opportunity to think about the situation and pick the most appropriate one, rather than just sticking with the most widely deployed and depended upon behaviour. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Intergrating the DOM and JavaScript (JSDOM)
Dean Edwards wrote: On 12/05/06, Andrew Fedoniouk [EMAIL PROTECTED] wrote: var checked = root.select(input[type=checkbox]:checked); You appear to be using a different DOM to everyone else. He's using his proprietary DOM extensions [1] found in his own browser. Though from what I gather from that documentation, that actually doesn't do the same thing as the functions you originally described because it returns an Element, not a boolean. [1] http://www.terrainformatica.com/sciter/Element.whtm -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] input type=text accept=
L. David Baron wrote: We might want to use the accept attribute in the future to indicate what types of content can be sent, and thus what types of input the user agent should allow. Overloading that to get a boolean for whether spellchecking should be enabled seems broken. AIUI, the accept attribute is just describing what type of input to allow. In this example, when text/plain is specified, the UA has just automatically determined that spell checking would be helpful for the user. Similarly, if text/html, application/javascript or */*+xml were specified, the browser could provide syntax checking. I don't think the spec should explicitly define type=text/plain as meaning UAs should provide spell checking, it can just provide that as an example of something a UA can do with it. What should the UA do with accept=text/plain;charset=X, where X is some charset that potentially differs from the page's encoding? e.g. if the page were served as text/html;charset=UTF-8 and contained input type=text accept=text/plain;charset=ISO-8859-1 Then how would that interact with form accept-charset=X? -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] http://whatwg.org/demos/repeat-01/
Christian Schmidt wrote: The demo on http://whatwg.org/demos/repeat-01/ claims to have server-side fallback for legacy clients. But the fallback doesn't work in IE6 - the form doesn't submit. Is this intended? That's because IE has failed to default to type=submit for unknown type attribute values. i.e. In current browsers, button type=add and button type=remove is supposed to equivalent to button type=submit. But in IE, it's equivalent to button type=button. The functionality can still be provided using JavaScript, or alternatively implementing the buttons using conditional comments like this: !--[if !IE]--button type=addAdd (!IE)/button!--![endif]-- !--[if IE]button type=submitAdd (IE)/button![endif]-- -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Simple numbers
Michel Fortin wrote: n dec=,123 456 789,12/n ... n base=16329F 2CA0/n What about using it to mark up roman numerals as well? Or, I guess, any other number system in the world? nMMVI/n Of course, people could use the roman numerals in Unicode: U+2160 to U+2183, but most people don't know they exist and it's much more convenient to type regular letters. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] input type=text accept=
L. David Baron wrote: The original use case, as I understand it, was roughly authors want to disable spell checking on some textareas. Authors should not have such control. Spell checking is a user agent feature for the *user* and the UA should allow the user to turn it on or off whenever they like. Why should the author have any say about that? Is the reason that they want to disable spellchecking only that the contents are not text/plain? I doubt it. Doing what you propose, especially if it is extended to other features, will just encourage authors to use incorrect MIME types to get particular side-effects in particular user agents. If the MIME type is to be used for anything related to spell checking, it should be used in a way that improves the spell checker's logic, not determine whether or not to enable it. For example, given a textarea with either accept=text/plain, no accept attribute (since text/plain should be considered the default for textarea); or any unknown or unsupported MIME type, then the UA can just use its ordinary spell checking algorithm. If, however, it uses accept=text/html or application/xml, etc., the spell checker could be made more intelligent by ignoring elements, attributes and their values (except for some special cases, like alt=... and title=..., where spell checking those values may still be useful). For determining whether or not to provide spell checking for input type=text, browsers should generally do so by default, unless it can be determined that it logically wouldn't be desired by the user. We will soon have type=email, url, etc. which covers quite a few use cases where spell checking wouldn't be desired. For other cases, browsers could use more intelligence to guess what the field is expecting. e.g. Password managers in UAs already guess fairly accurately when a username is being entered and that's another case where spell checking probably wouldn't be desired. For other unknown fields, browsers could use some Artificial Intelligence (AI) to learn what a user typically enables and disables spell checking for. e.g. If a user constantly disables spell checking for fields with input name=address1 or a labelAddress/label associated with the control (or similar variations), the AI could use that to determine that spell checking wouldn't be desired for similar fields. Using this approach, authors have no direct control over user agent behaviour, like spell checking. Instead, it is in their best interest to provide accurate information to enhance the user's experience. So it seems less likely to be abused by authors providing incorrect information in the hope of achieving specific behaviour. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] input type=text accept=
Alexey Feldgendler wrote: Maybe features like spellckeching, syntax highlighting and so on should be controlled via CSS? No, spell checking is a user agent feature that should be controlled by the UA and the user. Authors should have no explicit control over it. Besides, spell checking *is not* presentation, it is UA functionality and so it does not belong in the presentation layer. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] input type=text accept=
Alexey Feldgendler wrote: On Sun, 11 Jun 2006 21:54:16 +0700, Lachlan Hunt [EMAIL PROTECTED] wrote: One can also say that authors should not have explicit control over whether hyperlinks are underlined or not. The difference is that underlining is presentation, spell checking is not. The functionality of a link cannot be changed with CSS, likewise spell checking shouldn't either. Enabling or disabling spell checking doesn't change the functionality of an input. While the core functionality of allowing the user to enter text isn't changed, I'd consider spell checking to be part of the control's functionality, and so disabling it would change the functionality for the user. But misspelled words in an input with spellchecking enabled are underlined with a wavy red line (and the underlining style could even be changed by CSS), and that's presentation. Arguably, yes, but allowing authors to alter the presentation of misspelled words from the UAs default settings would only introduce usability problems. Users may not easily recognise any presentation set by the author as representing a missplled word. UAs may provide a way for the user to set their preferred presentation using some UA-specific means, but there's no need at all for the author to have any control over it. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] On accessibility
Simon Pieters wrote: I've spoken to a person who is blind about HTML5 and accessibility. I thought I'd send some of his thoughts to the list. ... He also says that he accesskeys shouldn't be dropped. Accesskey implementations need to be seriously improved if they are to be retained. There's significant evidence to show that there are very few, if any, safe keys available which don't clash with existing shortcut keys in browsers. http://www.wats.ca/show.php?contentid=43 If implementations can be modified so that accesskeys do not interfere with existing shortcut keys, then that's great. Perhaps they could offer a kind of web-apps mode where all Alt+[key] combinations are safe to be used by the web page, and then another mode where they retain their normal browser functions. But until something like that happens and proves successful, accesskeys should not be retained. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Spellchecking proposal #2
Ian Hickson wrote: textarea and input elements may have a new attribute specified, spellcheck. If specified, it must have either the value on or the value off (exactly, case-sensitive). The on value indicates that spellchecking is to be enabled, the off value indicates that spellchecking is to be disabled. If the attribute is omitted, the default value is to use the user preferences. I don't particularly like giving the authors any control over spell checking. For the majority of cases, I think browsers should become smart enough to know whether or not to enable/disable spell checking without any explicit author input, based on various heuristics (as I've written about before [1]). In other words, for most cases, authors should not need to use this attribute. UAs may allow the user to set this flag, and may have defaults that vary based and various heuristics or user preferences. That's good, but it really should be a *should* or a *must*. Ok, so how can we ensure that spell checking is enable for GMail's To: line but enabled for its Subject line? Ordinarily, input type=email would handle no spell checking for email addresses, but given that Gmail uses a textarea that contains both people's names and email addresses, that may be one case where heuristics may not give optimal results. If it were just e-mail addresses, it wouldn't particularly matter because spell checkers can already recognise e-mail addresses and not mark them as errors. But in this case (and others like it), the user should be able to very easily disable spell checking and have the browser remember that preference. Do you think that that one small use case is strong enough to warrant the use of a spellcheck attribute? Roughly what percentage of all use cases would you expect heuristics and user preferences to give suboptimal results, and thus require the author's suggestion? Is it really a major usability issue if a browser enables spell checking for a field where the user wouldn't want it, considering it can be easily disabled (or vice versa)? For contenteditable use cases, roughly what percentage of them would need the author to turn on or off spell checking? Given that the user can add semantics to their content using elements, browsers should be able to enable and disable spell checking for different sections. e.g. if a user starts entering code into a contenteditable section, UAs should be able to automatically disable spell checking for that content, while still checking the surrounding text. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=339127#c7 -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Spellchecking proposal #2
Matthew Raymond wrote: Another problem is |pattern|. Any spell checking mechanism will have to conform to the pattern value provided, which means either a really creative spell checking algorithm or turning spell checking off. I think the latter is probably the best idea, but it probably shouldn't be must. These are all the attributes that a spell checker will have to take into account: * type (can only spellcheck type=text) * accept (known MIME types should make spell checking more intelligent) * disabled * readonly * inputmode (maybe?) * list (if entered value is in datalist) * pattern -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Spellchecking proposal #2
Alexey Feldgendler wrote: On Fri, 23 Jun 2006 10:22:34 +0700, Lachlan Hunt [EMAIL PROTECTED] wrote: Roughly what percentage of all use cases would you expect heuristics and user preferences to give suboptimal results, and thus require the author's suggestion? IMHO we should not rely on unspecified heuristics. In some browsers, they work rather well, in some they might constantly fail. Leave heuristics for invalid pages, quirks mode etc -- or document these heuristics. Generally, that's true. But since spell checking is only a user agent feature intended for the user (it doesn't affect the page or author in any way) and interoperability between one browser's heuristics and another is not required. Browsers should be allowed to innovate as much as they like so they can come up with the best method that suits their users. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Spellchecking proposal #2
Alexey Feldgendler wrote: Even worse: when entering text in textarea, the user actually has a choice which language to write in. I think the user agent should provide, besides just the control to turn spellchecking on and off, a choice of languages. Of course the UA can provide such features, it's not up to the spec to document what features a browser can and cannot provide for their users, nor how to determine the user's input language. That is up to the browser. One browser may choose to base it on the lang attribute, another on the user's preferences, or even a combination of both. e.g. if a user has specified in their preferences that they can understand and write English and French. 1. The user visits a page with lang=en, the browser could automatically spell check in English. 2. The user visits another page with lang=fr, the browser spell checks in French. 3. The user visits a page with lang=de. Since the user hasn't indicated that they can understand or write the language, the browser can default to the user's most preferred language (either en or fr). In any case, the UA could always offer the user a way to change it at any time. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Spellchecking proposal #2
L. David Baron wrote: The problem is that heuristics are only heuristics when they operate on input written without knowledge of the heuristics. When the input was written with knowledge of the heuristics, they become de facto standards. Authors will learn what triggers spellchecking (or not) in Mozilla, and write whatever markup, however inappropriate, gives the choice of spellchecking that they want. Then other browsers will be forced to copy whatever Mozilla did. Theoretically, if the heuristics are written well enough, such that authors providing accurate information end up with the best usability by default, that shouldn't happen. If the heuristics are so bad that authors are left with little choice but to lie to improve the usability, then, yes, we'd end up with exactly that problem. However, in reality, I'd have to admit that such good heuristics are going to take a long time to research and develop well; and, especially in the early stages, probably won't be accurate enough for authors to rely on all the time. So if we're going to end up with a standard anyway, why not admit it and figure out what it should be rather than ending up there accidentally? Yes, I'd rather come up with a less-harmful solution now, regardless of semantic purity, than to repeat the mistakes of the past again and ending up with a more harmful defacto standard. The main problem with providing an explicit spell checking switch to the author is the potential for abuse. History has shown that authors will attempt to disable anything they don't like for any reason whatsoever, regardless of the usability benefits such features provide for users. We've seen that already with all of the following: * IE's smart tags: meta name=MSSmartTagsPreventParsing content=True * Google AutoLink (Some scripts were developed to workaround this) * IE's image toolbar: meta http-equiv=imagetoolbar content=no and img gallery=no) * AutoComplete (autocomplete=off) * Context menus (JavaScripts intercepting right click) * Showing link URLs in status bar (using window.status) * Removing browser chrome (in popups) * View Source (includes attempts to obfuscate source code with JS, disabling context menus, etc.) * Disabling printing (Some JS, works in IE only) * Disabling Save As..., (Some JS, works in IE only) * Disabling caching * And anything else they can get their grubby little hands on! I could easily imagine authors wanting to disable spell checking simply because the squiggly red underlines clash with their site's colour scheme. However, the proposed spellcheck attribute has one major advantage over all of those: it's being designed to allow the user to easily override it if they want to. I'd expect the result of that to be that authors won't bother doing so, unless spell checking really isn't suitable for the expected input, and it's an edge case where browser heuristics typically guess wrongly. I'd like to see some research done to find out exactly what kinds of input authors use input type=text, texarea and contenteditable for, beyond those already mentioned earlier in the thread. I'd also like to see research into the labels, name=, id= and other identifying information, commonly given to such fields, which can be used for developing heuristics. Although accept= is unlikely to be commonly used for textual input these days, it would be useful to see research into the kind of text-based content commonly entered (for which MIME types exist) that browsers could use to improve their spell checking logic (e.g. ignoring elements and attributes in textareas accepting text/html or XML). -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Spellchecking proposal #2
Matthew Paul Thomas wrote: On Jun 25, 2006, at 2:02 AM, Lachlan Hunt wrote: ... However, the proposed spellcheck attribute has one major advantage over all of those: it's being designed to allow the user to easily override it if they want to. But realistically, browsers won't allow the user to easily override it if they want to, because any interface for doing that would be absurd. For example, in Opera: | Select all #A | || | Check spelling| | Really check spelling | || What's the point of the separate Really check spelling item? If spell checking is turned on for the text field, the browser could check the Check spelling entry, and leave it unchecked if it's turned off. But there's far more creative things that browsers can do, browser UIs are continually improving and there's nothing stopping a browser from implementing an improved UI for it. For example, here's a few ideas that browsers could implement: * Status bar icon/text that indicates if spell checking is on or off, and if on, whether or not there are any errors (similar to that found in Microsoft Word). * Toolbar button used to toggle spell checking on or off and indicate it's state. * Context menu item (Opera already has this) * Floating toolbar that displays (possibly docked to one side of the text area) when the textarea has focus, with buttons for things like: spell checking, find and replace, cut, copy, paste, etc. I'm sure there are other people that know a lot more about UI design than I do, who could come up with some really creative and usable. We just have to look past pre-existing bad user interfaces and think outside the box a little. I'm starting to think we just need to define the attribute in a way that is semantic, and possibly come up with a new name to match. And also give non-normative guidelines about how other attributes may be used to improve the logic. For instance, the attribute could be defined like this: | The |on| value indicates that the expected user input will | primarily comprise natural human language. The off value | indicates that the expected user input will not. If the | attribute is not specified, user agents are free to use any | algorithm they like in order to determine the type of the | expected user input. | | User agents may use this to determine whether or not to | provide spell checking for the content by default. User | agents should provide a way for the user to override this | decision. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] [HTML5] Named start values for lists?
dolphinling wrote: HTML5 brings back the |start| attribute on ordered lists. This allows a list to semantically start with a number other than one. It seems like the major use case for this is to split lists up, so that a single list is marked by multiple ols. Other use cases include the ability to include an excerpt from another list in a page while retaining the list item indexes, or breaking a long list across several pages. e.g. Search results with 10 results per page could be marked up as a list: ol start=1 on the first page, ol start=11 on the second page, etc. Would it therefore make sense to allow named start values, so that the author doesn't have to go through and re-number everything when a new item is added at the top? And if so, should they be considered semantically one list? And if so, would it make sense for it to also apply to unordered lists, so that they can be split up, too? I recall similar suggestions made on www-html in the past. Something like this could be useful: ol id=part1 liItem 1/li liItem 2/li liItem 3/li /ol ol id=part2 continue=part1 liItem 4/li liItem 5/li liItem 6/li /ol However, there are several issues that would need to be addressed: * Should |continue| be an IDREF that can only continue a previous list in the same page, or should it be a URI that can continue lists from other pages? * Can it be defined and implemented in a way that avoids circular references. e.g. ol id=part1 continue=part2/ ol id=part2 continue=part1/ * What does it mean if ol contine=foo references a ul id=foo? Should it only be able to link lists of the same type? (i.e. ol with another ol and ul with another ul) * What does it mean if it references any other element that isn't a ul or ol? * What should happen if it references a non-existent element? * What does it mean if two lists continue from the same previous list? e.g. ol id=part1 continue=part2/ ol id=part2 continue=part1/ ol id=part3 continue=part1/ * How are references duplicate IDs handled in this situation? (That could probably be the same way label for= handles it) * Which takes precedence out of ol continue=part1 start=2 and li value=3? * Backwards compatibility is also an issue, though it could possibly be handled with some JavaScript that dynamically calculates and sets the start attribute. * Would implementations have difficulty with re-numbering list items in linked lists, when a new li is dynamically inserted into a previous list? -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Spellchecking proposal #2
Matthew Paul Thomas wrote: On Jun 25, 2006, at 11:59 PM, Lachlan Hunt wrote: Matthew Paul Thomas wrote: ... But realistically, browsers won't allow the user to easily override it if they want to, because any interface for doing that would be absurd. ... I'm sure there are other people that know a lot more about UI design than I do, who could come up with some really creative and usable. The problem is not with which GUI controls you choose; it's with the amount of attention demanded by the underlying situation. Spellchecking would seemingly be turning itself off for a completely non-obvious reason; and to make it obvious, you would have to make the spellchecking feature more prominent than its importance permits. That would happen with either the author specified attribute approach, or the heuristics approach where browsers make an educated guess based on the semantics and surrounding content. The only way that wouldn't happen is if spell checking was completely controlled by the user, so that it remains in the state it was last set to for all controls; or defaults to being either on or off for every control, regardless of what the user last specified. In thpse cases, it's arguably more important for the spell checking control to be more prominent in the UI. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] [HTML5] Named start values for lists?
Henri Sivonen wrote: On Jun 27, 2006, at 09:46, Lachlan Hunt wrote: ol id=part1 ... /ol ol id=part2 continue=part1 ... /ol However, there are several issues that would need to be addressed: Hopefully, the issue list adequately demonstrates that the continue attribute is way too complicated considering that the old start attribute solves the numbering problem in a very pragmatic way. The start and value attributes certainly do solve the majority of the use cases. They don't semantically link the lists together and they place the responsibility of calculating the starting values upon the authoring/publishing system, rather than the browser. What are the specific use cases that require the lists to be semantically linked? If there are any, could they be addressed using a microformats approach? e.g. Lists with class=split-list (or any other class name) that share the same title could be defined by a microformat to be linked lists. Perhaps, the class name isn't even required, the matching titles could be sufficient. ol class=split-list title=Fruit liApples/li liBananasli /ol ol class=split-list title=Fruit start=3 liCoconuts/li liDates/li liFigs/li /ol -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] [HTML5] Named start values for lists?
James Graham wrote: * Would implementations have difficulty with re-numbering list items in linked lists, when a new li is dynamically inserted into a previous list? I would hope not since that's one of the big attractions of this model. Perhaps not so much for browsers that natively support it, but for a JS implementation designed for backwards compatibility in current browsers, it would have to listen for the the events like DOMNodeInserted, DOMNodeRemoved and DOMAttrModified (and possibly some others). They'd be needed to handle all cases of list items or entire lists being inserted or removed, as well as changing values for the |start|, |value| and |continue| attributes for all ol and li elements, and then update all linked lists appropriately. That could get quite complex and complexity increases the chances of introducing bugs. Besides, not all current browsers support those events, which would make a JS implementation quite limited. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] image captions
Ben Meadowcroft wrote: Perhaps a better method would be using the longdesc attribute to associate a caption with an image. Specifically we could point the image to fragment within the current page and give an explicit association in this manner. img src=man.gif alt=A Man longdesc=#manCaption / p id=manCaptionA more full description of the image/p I think accessibility experts would have serious issues with this. A caption doesn't even come close to being a good long description. See what Joe Clark has to say about writing good long descriptions. http://joeclark.org/book/sashay/serialization/Chapter06.html#h1-1715 -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] image captions
Michel Fortin wrote:
figure
captionFigure 1: Some image/caption
img src=...
/figure
I agree that structure is the best approach. That allows for good
styling, by setting the following:
figure { display: table; caption-side: bottom; }
figure img { display: block; }
caption { display: table-caption; }
The only problem is that it isn't very backwards compatible. Firefox
doesn't include caption in the DOM outside of a table. Moving the
caption after the image in the source and setting display: block; on the
image gives reasonable results in Firefox and Opera because the img is a
child of figure, but not in IE because figure and img are treated as
siblings.
Using the microformat approach instead, like the following, gives better
backwards compatibility, but at the expense of proper semantic elements.
div class=figure
img ...
p class=captionFigure 1: Some image/p
/div
We could also use a single-cell table for this, but this approach could
be considered abuse and IE doesn't seem to support 'caption-side', but
does support the deprecated align attribute on caption.
table class=figure
captionFigure 1: Some image/caption
tr
tdimg ... /td
/tr
/table
Whatever approach we eventually decide upon, it should be able to handle
captions for a variety of strucutres, not just images. This includes:
* Blocks of code and sample input/output
* Lists
* object, embed, img and maybe iframe
Along with tables (which already support them) I think that would cover
every use case for captions.
--
Lachlan Hunt
http://lachy.id.au/
Re: [whatwg] Where did the rev attribute go?
Charles Iliya Krempeaux wrote: What happened to the rev attribute? The problem with the rev attribute is that it's difficult for authors to understand the concept of a reverse link relationship; and compared with rel, it's hardly ever used. There's only one use of rev that I'm aware of which is listed on microformats.org. It's for vote-links, but I don't think those relationships should be used anyway. Neither the a or link element seems to have it anymore... I think it should still be present, but it's semantics would need to be clarified and explained. We should probably also identify some real use cases where it is actually useful for authors. The rev attribute is important for allowing what I call opaque semantics. Can you more clearly define what you mean by opaque semantics? -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] input type=country?
David Håsäther wrote: But what if you use a browser with an old list, and your contry isn't listed. Or are you proposing that browsers download a list every time? Many modern browsers already periodically check for updates. Such lists could be downloaded like any other update, as required. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] [WF2] Typo in 2.9 The autocomplete attribute
dolphinling wrote: Lachlan Hunt wrote: dolphinling wrote: http://www.w3.org/TR/web-forms-2/#the-autocomplete | The autocomplete attribute applies to the text, password date-related, | time-related, numeric, email, and url controls. There needs to be a comma after password. And no comma after email. No! Oxford comma FTW! :-) There are times when the Oxford comma is appropriate and other times when it is not. http://en.wikipedia.org/wiki/Serial_comma#Style_guides_opposing_mandatory_use I don't think this case is appropriate; but I'll leave it up to Hixie to decide, since it doesn't really affect anything important. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] href on any element
Keryx webb wrote: Shut me up and give me a link if this has been discussed before, but I can't find it on Google. Has there been any discussion of allowing the href-attribute in (almost) any element, as in XHTML 2.0? Personally I think this is the one killer feature of XHTML 2 and I would soo much like it ASAP in all browsers. What are the perceived benefits that make it such a killer feature? abbr href=http://www.whatwg.org/; title=Web Hypertext Application Technology Working GroupWHATWG/abbr makes perfect sense to me. Theoretically, for XHTML, you could use XLink and write this (assuming the appropriate namespace is declared) abbr xl:type=simple xl:href=http://www.whatwg.org/; title=Web Hypertext Application Technology Working GroupWHATWG/abbr But my tests with Firefox showed that, even though it supports simple XLink links for generic XML, that doesn't work for XHTML elements. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] href on any element
Ian Hickson wrote: It isn't always clear what it would mean, either (consider col href=, or optgroup href=). If the feature were to be added to Web Apps 2.0 (or other future spec) I think it would be sensible to limit it to inline, non-interactive, non-empty elements (e.g. abbr, em, strong, etc.) and a few other selected elements (e.g. li and td). It should not apply to elements like col, br, hr, input, select, etc. It's arguably a very minor improvement, The only benefit I'm aware of is the convenience it provides to authors for hand coding, but that benefit is negligible when you consider the abilities of many authoring tools these days. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] href on any element
Andrew Fedoniouk wrote: Ian Hickson wrote: a href= h2.../h2 p.../p /a If we will change model of A from !ELEMENT A - - (%inline;)* -(A) -- anchor -- to something else then it will create implications for parser. What implications? Changing the formal content model of an element doesn't change the way a parser needs to work. Ian's example above is very similar to some real world examples I've seen and browser's already handle it just fine. The DOM looks like this: A +-H2 + P -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] href on any element
Andrew Fedoniouk wrote: Lachlan Hunt wrote: Andrew Fedoniouk wrote: Ian Hickson wrote: a href= h2.../h2 p.../p /a If we will change model of A from !ELEMENT A - - (%inline;)* -(A) -- anchor -- to something else then it will create implications for parser. What implications? Changing the formal content model of an element doesn't change the way a parser needs to work. Ian's example above is very similar to some real world examples I've seen and browser's already handle it just fine. These are non-conformant browsers :) No, in this case, they're just handling the non-conformant content in the most sane way, which I believe (in this case) is correct handling according to traditional SGML rules. See the Parse Tree produced by the validator for that construct (ignore the 2 expected validation errors): http://validator.w3.org/check?uri=data%3Atext%2Fhtml%3Bcharset%3Dutf-8%2C%253C%21DOCTYPE%2520a%2520PUBLIC%2520%2522-%252F%252FW3C%252F%252FDTD%2520HTML%25204.01%252F%252FEN%2522%253E%250D%250A%253Ca%2520href%253D%2522%2523%2522%253E%250D%250A%2520%2520%253Ch2%253E...%253C%252Fh2%253E%250D%250A%2520%2520%253Cp%253E...%253C%252Fp%253E%250D%250A%253C%252Fa%253E%2520charset=%28detect+automatically%29doctype=Inlinesp=1 A simply cannot have content other than inline constructions. According to the formal content model, yes, but when a browser encounters a real world document has that construct, what do you think the browser should do with it? What UA should do in this case is not specified. Using this is as bad as violation of following: See section 8 of the Web Apps 1.0 spec. http://www.whatwg.org/specs/web-apps/current-work/#parsing The DOM looks like this: A +-H2 + P And what is semantical meaning of that? Some hyperlinked section? The A element is just defined as a hyperlink. Whether or not it's a section is irrelevant. If yes then let it be just : section href=... h2... p... /section But that isn't backwards compatible. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Lists, ins/del, and a
Michel Fortin wrote: How can we markup removed or inserted list items? Here's a general idea: ul insliSome list item/li/ins delliAnother list item/li/del /ul This can be solved by putting the ins and del elements as the only child nodes of the li elements instead. ul liinsSome list item/ins/li lidelAnother list item/del/li /ul -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Fw: Lists, ins/del, and a
Andrew Fedoniouk wrote: someListElement.select( li:not(li li), foo); That selector won't work anyway, because (according to the Selectors spec) :not() can only contain a single simple selector. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Lists, ins/del, and a
Andrew Fedoniouk wrote: Lets forget about ins or del as anyway this is better ol li class=new inversion=Some list item/li li class=removed inversion=Another list item/li /ol I don't know what the inversion attribute is supposed to mean, but the class attribute is semantically meaningless. However, we could introduce the edit and datetime attributes from the XHTML 2.0 draft's Edit Attributes Module [1]. Then we could just define that ins and del are semantically equivalent to div edit=inserted and div edit=deleted (or span, when used as inline elements), respectively. That way, we could use this: ul li edit=insertedSome list item/li li edit=deletedAnother list item/li li edit=changedModified list item/li li edit=movedMoved list item/li /ul [1] http://www.w3.org/TR/xhtml2/mod-edit.html -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Lists, ins/del, and a
Ric Hardacre wrote: Another related thought we could discuss for revision control using ins and del is that they could do with a couple of attributes, a datetime http://www.w3.org/TR/html401/struct/text.html#adef-datetime and an author: pOn a dull and dreary afternoon ins datetime=2006-27-08 12:34:56 author=Ric HardacreI added this text while/ins the rain poured down/p Maybe. What's the use case and what benefit does it provide? Would a name be a suitable value, or would a URI pointing to more info about the author be better (e.g. linking to the author's profile or homepage). Would the use cases be better handled using CVS or SVN on the back end? Would any user need to know which author edited something? I could be wrong, but I believe author information is recorded by office applications (e.g. Word, OpenOffice) when revision control is enabled; but, again, would it be useful to have it saved in HTML? -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Lists, ins/del, and a
Anne van Kesteren wrote:
del { display: none }
you'll see a one-item list for my markup, while for your markup you'll
see a second, empty list item.
That could be seen as a limitation of the styling language. It has been
repeated many times on this list that styling should not be taken into
account when designing markup.
But you do have to design the markup language in a way that satisfies
the use cases. In this case, it clearly doesn't satisfy at least one of
them.
The edit attribute would meet this one, as you could use:
li[edit=deleted] { display: none; }
It's even somewhat backwards compatible with current browsers.
--
Lachlan Hunt
http://lachy.id.au/
Re: [whatwg] Lists, ins/del, and a
Lachlan Hunt wrote: we could introduce the edit and datetime attributes from the XHTML 2.0 draft's Edit Attributes Module [1]. I just realised that the datetime attribute from the Edit module would clash with the proposed datetime attribute of the t element [1]. e.g. What would the datetime attribute mean in this? t edit=inserted datetime=2006-08-3131 Aug 2006/t It could either mean that the markup was inserted on 2006-08-31 or that the content is a date equivalent to 2006-08-31. A possible solution could be to keep edit and datetime attributes for editing and rename the datetime attribute for the t element to something else (e.g. dt) e.g. t dt=2006-08-3131 Aug 2006/t t dt=2006-08-31 edit=inserted datetime=2006-09-01T12:30Z31 Aug 2006/t The problem with that is that authors may get confused and use datetime instead of dt, or vice versa. Alternatively, we could use the title attribute instead. e.g. t title=2006-08-3131 Aug 2006/t That has the advantage of actually making the ISO date accessible to users using the existing tooltip mechansim and is similar to the current abuse of the abbr element for the datetime microformat [2]. [1] http://www.whatwg.org/specs/web-apps/current-work/#the-t [2] http://microformats.org/wiki/datetime-design-pattern -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Hacking away on forms ... (fwd)
Francisco Monteiro wrote: What does tags have to do with the DOM? We're talking about the DOM that IE produces when given specific markup. It has everything to do with the DOM! Exactly, is this thread becoming a Opera marketing ploy? What the...? -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Hacking away on forms ... (fwd)
Dave Raggett wrote: You can reproduce my tests by pointing your browser at: http://people.w3.org/~dsr/dom/test.html OK, I have the discovered the reason for the discrepancy in our results. Apparently IE handles exactly the same markup differently depending upon how it is added to the page. If you load my test case [1] in IE, tests A through E are styled, but test F isn't. This shows the following: IE will only allow styling of elements with namespace prefixes that have been either explicitly or implicitly declared. There are two ways to explicitly declare a namespace in IE: 1. html xmlns:foo=http://example.org/foo; 2. ?xml:namespace prefix = foo ns = http://example.org/foo; / In both cases, the URI may be omitted. When a Custom Tag (the name Microsoft have given elements with namespace prefixes in HTML) is added using either innerHTML or document.write(), the PI that declares the namespace will be implicitly generated using the prefix but with no actual namespace name. This explains why I was getting different results using the Live DOM Viewer because it uses innerHTML to copy the markup from the text box to the rendering area. That means that IE was implicitly declaring the namespace of all Custom Tags in my tests. [1] http://lachy.id.au/dev/2006/09/custom-tags -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Fwd: Re: [xhtml-role] Extensibility of XHTML 1 and XHTML 1.1 (PR#9627)
Anne van Kesteren forwarded this from Shane McCarron: XHTML2 will be using the same namespace as XHTML1, and there will not be two modules. Great news! I wonder how open the HTML WG will be with regards to working with the WHATWG and HTML 5, especially now that the 2 specs will share the same namespace. If we don't resolve the incompatibilities, one of the specs will simply be doomed to failure. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] [WF2] Typo in 2.9 The autocomplete attribute
Ian Hickson wrote: On Mon, 28 Aug 2006, Lachlan Hunt wrote: dolphinling wrote: http://www.w3.org/TR/web-forms-2/#the-autocomplete | The autocomplete attribute applies to the text, password date-related, | time-related, numeric, email, and url controls. There needs to be a comma after password. Fixed. Doesn't appear to be fixed yet. Maybe you just forget to check in the changes. And no comma after email. I disagree, but this is highly editorial, so... :-) Ok, that's fine. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Canvas lack of drawString method
Alfonso Baqueiro wrote: The canvas component is very promising, but the lack of drawString method could be a great error for its success, this lack is a huge limitation, how could you resolve this problem? Just for a bit of fun, I created a demo to show how it is already possible to render text on canvas. This technique has certainly got many limitations and could never be made as good as a native implementation, but it works Firefox, Opera and Safari. http://lachy.id.au/dev/2006/10/canvas-text -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Table integrity and conformance
some sort of testing with the axis attribute too, or maybe we should drop it. I've never used axis. I've never seen it used by anyone else. It didn't seem to show up in the Google Web Stats you did previously. I don't know anyone who understands how it can be used or what it's useful for. I don't know any UA, including assistive technology, that supports it (though that needs to be verified). I see no compelling reason to keep it, despite the theoretical benefits given in the HTML4 spec. (Indeed maybe we should drop some of the others, too.) I'd say drop all of these because they're either presentational or not supported. * align * valign * char * charoff * width * height * border * frame * rules * cellspacing * cellpadding All of these attributes should be kept, because they are supported and non-presentational. TABLE * summary (supported by screen readers) TH and TD * abbr (I think that's supported by screen readers, but need to verify) * headers * scope * rowspan * colspan COL and COLGROUP * span [1] http://www.w3.org/TR/CSS21/tables.html#q7 -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] innerHTML in XML
Anne van Kesteren wrote: foo bar/ bar/ /foo How can foo.innerHTML be well-formed here? It could be if it were treated as an external parsed entity. http://www.w3.org/TR/REC-xml/#NT-extParsedEnt -- Lachlan Hunt http://lachy.id.au/
[whatwg] Joe Clark's Criticisms of the WHATWG and HTML 5
Hi, I thought Joe Clark's opinions and criticisms of the WHATWG and HTML5 might be of interest to people here. http://blog.fawny.org/2006/10/28/tbl-html/ I don't agree with everything he said, but he points out a lot of issues and lists several limitations and suggestions. Some of the suggestions are already included or have at least been discussed, but some a new and worth looking into. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Tim BL's HTML WG announcement and WHAT WG
Karl Dubost wrote: What will be interesting to see if they all perl, python, C, Ruby, etc. libraries will follow this model once it is defined. It would be good I guess for the new WG to gather implementation experience, not only in desktop browsers but also in all applications consuming or producing HTML. Though IMHO, layout engines are just one part of it. The fact is that whatever we define must be compatible with desktop browsers above everything else. That is what the vast majority of authors write HTML for, it's what they test in and it's how they expect all other tools to handle it. I'm not saying that getting implementation experience from other tools wouldn't be valuable, just that it's far more practical for other tools to base their implementations on desktop browsers, than the other way around. Disgusted of Tunbridge Wells wrote: In addition, if the role of the W3C is simply to to place its seal of approval on what /is/, rather than on what /should be/, then I for one would find that a very disturbing (not to say depressing) state of affairs. The W3C needs to release specs that can actually be useful in the real world, not ones that are just nice in theory, but totally impractical to implement. For HTML, if the W3C released another specification that required SGML parsing, it would be completely useless because it is practically impossible for browser vendors to conform to such requirements without breaking a significant portion of existing web sites. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] How not to fix HTML
Ian Hickson wrote: Joe Clark wrote: http://blog.fawny.org/2006/10/28/tbl-html/ FYI, my response to that his here. http://lachy.id.au/log/2006/10/fixing-html * Allow multiple uses of the same id/label in a form and suddenly it becomes possible to mark up multiple-choice questionnaires accessibly. Could you elaborate on this? I'm not sure how this would work with the DOM, but I'm sure there's a way of addressing the use case you have in mind. I believe the issue is with the way screen readers handle existing forms. The problem is that each radio button or checkbox has it's own label, but the whole group is often associated with a single question and there is no way mark that up. e.g. pGender: label for=minput type=radio id=m name=gender value=m Male/label label for=finput type=radio id=f name=gender value=f Female/label /p In this case, when screen readers are in forms mode and the user is tabbing between form controls, it will only read out Male and Female, it won't read out Gender:. In this specific case, that's probably not a major issue because male and female are fairly self explanitory, but there are many cases where it's not. There are workarounds using fieldset and legend for the question, like this. fieldset legendGender:/legend label for=minput type=radio id=m name=gender value=m Male/label label for=finput type=radio id=f name=gender value=f Female/label /fieldset Because of the way screen readers work, they now read out Gender: Male and Gender: Female as they tab to each control. This example demonstrates this technique. http://www.alistapart.com/d/prettyaccessibleforms/example_3/ The problem with that technique is that, because of the way legends are rendered in browsers, styling is somewhat restricted. There are a few possible ways to address this that I have thought of. 1. Allow labels to be associated with a group of form controls by referring to the control name. plabel group=genderGender:/label label for=minput type=radio id=m name=gender value=m info=gender Male/label label for=finput type=radio id=f name=gender value=f info=gender Female/label /p (I know the for attributes aren't technically required here, but due to current screen reader limitations, they are) 2. Allow labels to be associated with multiple controls, using a space separated list of IDREFs (like the headers attribute in tables). plabel for=m fGender:/label label for=minput type=radio id=m name=gender value=m info=gender Male/label label for=finput type=radio id=f name=gender value=f info=gender Female/label /p 3. Allow form controls to refer to additional labels. pspan id=genderGender:/span label for=minput type=radio id=m name=gender value=m info=gender Male/label label for=finput type=radio id=f name=gender value=f info=gender Female/label /p 4. Same as #3, but allow the link from the label elements instead. pspan id=genderGender:/span label for=m info=genderinput type=radio id=m name=gender value=m Male/label label for=f info=genderinput type=radio id=f name=gender value=f Female/label /p I think #1 is the best of these options because it's more convenient to type a single name, than multiple IDs. Plus, if a new control gets added to the group, it's implicitly associated without having to update the for attribute with the new ID. I don't particularly like #3 and #4, but they were my first thoughts, so I listed them anyway. Start a Working Group For Web Accessibility, independent from the W3C, and write an alternative to WCAG2. In about 2 years, if the work you've done starts getting more traction than the W3C's work, then you'll get their attention and then they'll start fixing the WCAG work. Joe has already decided to take a similar approach with his WCAG Samurai. However, he's keeping it top secret. There's virtually no information about it and no way to participate or even keep track of the work without an invitation. http://alistapart.com/articles/tohellwithwcag2/#WCAG-documents:WCAGSamurai http://wcagsamurai.org/ -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] How not to fix HTML
Charles Iliya Krempeaux wrote: http://lachy.id.au/log/2006/10/fixing-html That link doesn't work. (I get a 404.) Fixed, thanks. There seems to ge a bug WordPress that causes posts to get marked as private for some unknown reason. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Video
Ian Hickson wrote: On Mon, 30 Oct 2006, Charles Iliya Krempeaux wrote: Would you be open to hearing suggestions about how to add native video and video player support? Sure. FWIW, there's a lot of interest in browser vendors about introducing a video element or some such (or maybe making browsers natively support video in object, or both). I don't like the idea of a video element just for the purpose of embedding video. What I think needs to happen is for browser vendors and plugin vendors to improve the usability and add better support for video formats. Places like YouTube and Google Video work around this by building their own interface using Flash, which handles multiple formats seamlessly for the user. With the current plugin architecture, each plugin provides it's own UI. So that, for example, a Quick Time video (.mov) gets the Quick Time UI and a WMV gets Windows Media Player. That's a bad user experience, the browser should provide a common UI for all videos, regardless of the format. Perhaps, to go along with the Audio() interface, we could have a Video() interface as well. Maybe it would be wise to introduce a MultiMedia() interface, which is then inherited by both the Audio() and Video() interfaces and extended by each with APIs specifically for their respective media. e.g. Video() could have an API for capturing a frame and exporting it as a JPG or PNG. Those interfaces could also possibly be implemented on the object and embed elements. Charles Iliya Krempeaux wrote: #1: A natively supported video format. (Like the way GIF's, JPEG's, and PNG's are natively supported.) Defining which video format for browsers to support is out of scope of the WHATWG and HTML5. However, I do agree that there needs to be a more widely supported format so that websites don't have to offer the user a choice (commonly WMV, Quick Time and Real). If offered a choice, it should only be to pick one suitable for their bandwidth. Given this, I would suggest Ogg Theora be the natively supported video format common to all browsers. It would be very nice to have a widely supported, non-proprietary, patent free format on the web, which is also completely free of DRM. I would love to see Ogg Vorbis/Theora become as successful in the audio and video market as PNG has for images, but the current problem holding it back is the lack of implementation in the major media players and browsers. In comparison, alpha transparency in PNG hasn't taken off significantly despite having major benefits over index transparency, primarily because IE hasn't supported it until now. I suspect that will change once IE7 becomes more widely deployed. I aware that there are many implementations of ogg available, but Windows Media Player, Quick Time and Real Player don't. Of course, it would also be nice if VLC (when it matures enough) became the most popular player, but that's not going to happen any time soon. So, I think it would be a good idea for the video and audio community to strongly encourage native implementation of ogg in the major players and authoring tools. Once the major players support it, we'd then need to see digital cameras and other authoring equipment adopt ogg as the native format, instead of MPEG and Quick Time. Aside from the companies who have a stake in proprietary formats, I'm sure they would like to because they could save money on licensing fees. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Video
Charles Iliya Krempeaux wrote: On 10/30/06, Lachlan Hunt [EMAIL PROTECTED] wrote: Places like YouTube and Google Video work around this by building their own interface using Flash, which handles multiple formats seamlessly for the user. Not exactly. Flash players only play FLV video files. And that's it (AFAIK). Behind the scenses... server-side... other video formats a transcoded to FLV. Ok, I wasn't sure about that. but the current problem holding it back is the lack of implementation in the major media players and browsers. This might be the chicken and the egg problem. That's not a problem. The egg came first, the chicken evolved later. :-) Besides, many people are already publishing audio and video using ogg, we just need the native implementations in major media players to bring it more into the mainstream. I aware that there are many implementations of ogg available, but Windows Media Player, Quick Time and Real Player don't. http://www.illiminable.com/ogg/ http://xiph.org/quicktime/ https://helixcommunity.org/frs/?group_id=7 Unfortunately, they're not native implementations, which is a problem. If they shipped with the players, it would be great! -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Video
Alexey Feldgendler wrote: Flash player does not ship with browsers, at least not with every browser, but this doesn't prevent Flash from being widely used. Initially, the Flash Player plug-in was not bundled with popular web browsers and users had to visit Macromedia website to download it, but as of year 2000, the Flash Player was already being distributed with all AOL, Netscape and Internet Explorer browsers. Two years later it shipped with all releases of Windows XP. -- Wikipedia http://en.wikipedia.org/wiki/Adobe_Flash#History Besides, Flash is one of the few successful plugins. Many others that have failed. -- Lachlan Hunt http://lachy.id.au/
[whatwg] Footnotes, endnotes, sidenotes
Ian Hickson wrote: * note and reference for footnotes, endnotes, and sidenotes (not aside in “HTML5”) If anyone has any ideas on this, please post them to the list. (The CSS group is also looking at footnotes closely.) It would useful to look at previous work and discussion on this issue. http://www.cs.tut.fi/~jkorpela/www/fn.html http://www.w3.org/MarkUp/html3/footnotes.html http://www.sagehill.net/docbookxsl/HTMLFootnotes.html http://daringfireball.net/2005/07/footnotes http://daringfireball.net/2005/08/notes_on_notes http://www.quirksmode.org/blog/archives/2005/07/footnotes_on_th.html Also, Wikipedia's markup for footnotes is good example of current practice and also a good use case for them. This example came from the HTML article. http://en.wikipedia.org/wiki/HTML sup id=_ref-0 class=referencea style= href=#_note-0 title=[1]/a/sup ol class=references li id=_note-0ba href=#_ref-0 title=^/a/b cite class=book style=font-style: normal;Raggett, Dave (1998). ia href=http://www.w3.org/People/Raggett/book4/ch02.html; class=external text title=http://www.w3.org/People/Raggett/book4/ch02.html;Raggett on HTML 4/a/i. Addison-Wesley, chap. 2: A history of HTML. a href=/w/index.php?title=Special:Booksourcesamp;isbn=0201178052 class=internalISBN 0-201-17805-2/a./cite/li ... /ol The actual wiki markup might be a useful reference too. http://en.wikipedia.org/wiki/Wikipedia:Footnotes As for sidenotes, the markup you've used in the spec are good examples: p class=issueThis section on the codea href=#tabindex0tabindex/a/code attribute needs to be checked for backwards-compatibility. span class=issueWe could make this into a string value that acts as a Hint for why the command is disabled./span One thing to consider when looking at footnotes is would the title= attribute handle this use case as well as what I'm proposing?. If the answer is yes, or almost, then it's probably not a good idea to introduce the new feature. I really don't think so. There are accessibility and usability issues with the title attribute. * Screen readers don't read the title attribute by default. * Tooltips are inaccessible (in current implementations) to keyboard users, they require hovering with a mouse. * Users have no clear way of identifying which content has a tool tip, except for maybe abbr and acronym (which get a dotted border in FF). * It's also limited to plain text, when even the example from wikipedia contains additional markup. The first 3 issues could possibly be addressed by changing the rendering, but how do you identify a regular title attribute from one intended to be a footnote? Would it be appropriate for all of them to be treated as footnotes? I don't think so. James Graham wrote: I think and distinction between footnotes, sidenotes and endnotes is basically presentational and whilst we should try to ensure that markup+CSS can create all three appearances we shouldn't treat them distinctly. I agree that the distinction between footnotes and endnotes is just presentational. But I'm not so sure about sidenotes. We'd really need to look at books that make use of them and see on what basis authors actually decide to use footnotes or sidenotes. Do some authors use footnotes and sidenotes in the same book, or they exclusively choose one over the other based solely on presentation? Also, it wouldn't particularly matter if footnotes ended up being rendered as endnotes in printed media (which is how exisiting browsers render the wikipedia-style markup) but it would be nice if browsers could render them as footnotes at the bottom of each page. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] How not to fix HTML
Matthew Raymond wrote: Here's a thought: | p | grouplabel for=genderGender:/grouplabel |labelinput type=radio name=gender value=mMale/label |labelinput type=radio name=gender value=fFemale/label | /p The element grouplabel gives the label for the group. That's similar to the label group= idea I posted. The |for| attribute in this case takes a name rather than and ID, I think that could be somewhat confusing using the same attribute name for different, but somewhat related, features. That's why I like the group attribute, because then there's no chance for confusion about whether it takes a name or id in this context. Also, label already supported, so there's fewer backwards compatibility issues. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Footnotes, endnotes, sidenotes
Sander Tekelenburg wrote: At 20:35 -0800 UTC, on 2006-10-31, Jonathan Worent wrote: I came across an article by Jesper Tverskov titled The benefits of footnotes in webpages. (http://www.smackthemouse.com/footnotes) It may be of interest. IMO the problems with the title attribute he lists are in fact browser implementation poverty, not title attribute problems. Same for his arguments for footnotes. That's true, but they are all real world, practical problems which still haven't been solved in the past 10 years and there's no evidence to suggest that the situation will change any time soon. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] How not to fix HTML
Matthew Raymond wrote: The element grouplabel gives the label for the group. That's similar to the label group= idea I posted. True, but it eliminates the need for an |info| attribute on every element. Oops. Those info attributes were a copy and paste error. They should have been removed from #1 and #2, cause I wrote #3 first and copied that for the rest. The group attribute in my examples was referring to the name attribute, like the for attribute in yours. A better solution would be to use input group=, where the value of |group| is the value of the controls' |name| attributes and not the value of |info| attributes, thus eliminating the need for |info|. Assuming you meant label group=, that's exactly what I intended in my examples. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] How not to fix HTML
Lachlan Hunt wrote: Ian Hickson wrote: Joe Clark wrote: http://blog.fawny.org/2006/10/28/tbl-html/ FYI, my response to that his here. http://lachy.id.au/log/2006/10/fixing-html Joe Clark has responed. http://lachy.id.au/log/2006/10/fixing-html#comment-713 His comment is copied here for discussion. annotation: A lot of things are annotations in PDF, including comments. We could use annotation for suprasegmental features like very long tooltips with block-level content, whose appearance could be user-controlled (and accessible by screen readers and keyboard). We could also just call blog comments annotations. part, section and article (some in “HTML5”): A part can be a chapter (we could also just say “chapter”). Articles could be included in sections that are in turn included in parts and served as pages. caption generically applicable to tables and figures: We can call it legend if you’d like. bibliographies, tables of contents, and indices (some in “HTML5”): “For tables of contents, isn’t existing list markup good enough?” No, I’d prefer stronger associations between ToC and item than just a hyperlink. I would also like to be able to suppress display of ToC in some presentations. Of course I can do that with divs. nonstruct for generic groupings: We can use it to group noncontiguous elements, useful in e.g. error reports on submitted forms or Ajax applications. E.g., nonstruct group=”X”. Error reports are a good use case, but I'm not sure that nonstruct would be best for them. There are accessibility reasons for explicitly marking up error information, particularly for forms, and current accessible techniques include writing the error message within the label and/or fieldset's legend to force screen readers to read it out. Some markup for errors and a way to associate that error with a control might be useful. formula: “But doesn’t that fit into the category of science and mathematics that you had issues with earlier?” Yes, but this one we *need*. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] [HTML5] 3.10.9. The |abbr| element
James Graham wrote: Lachlan Hunt wrote: Abbreviation expansions should only be supplied when they help the reader to understand the content, not just because the word happens to be an abbreviation. I agree, unless using abbr with no title is useful to get the correct rendering of abbreviations in non-visual media. Using abbr without a title would be useful if it automatically referred to a previous instance with the title attribute. e.g. You could mark up the first occurance as like this abbr title=As Far as I KnowAFAIK/abbr Then, later in the document, you could use it without the title attribute abbrAFAIK/abbr and a UA could allow the user to discover the expansion. This idea is already somewhat supported in the current draft, but requires that it references the defining term of a previously marked up dfn, rather than just another occurrence of the same abbreviation. IMHO, that part of the spec needs fixing. http://www.whatwg.org/specs/web-apps/current-work/#the-dfn http://www.whatwg.org/specs/web-apps/current-work/#the-abbr -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Mail list subscription
Elliotte Harold wrote: It would be nice if I could send a comment without having to subscribe to the mailing list first. Many people may notice one or two small issues but not want to participate in day-to-day discussions. There are several options for people in that situation. 1. Subscribe to the list, but disable mail delivery. This way, you can still post when you have something to say, but don't receive all the e-mails. http://lists.whatwg.org/listinfo.cgi/whatwg-whatwg.org * Fill in your e-mail address and click Unsubscribe or edit options * Fill in your password on the next page and log in * Disable the Mail Delivery option 2. Send your comments directly to Ian Hickson. * whatwg at hixie.ch 3. Join the discussion on IRC. * #whatwg on freenode. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] JSON encoding
Douglas Crockford wrote: I think the hazard is very real and very serious. I don't see any additional expressiveness enabled by toJSONString. This is a convenience issue. Having toJSONString as a builtin is a convenience, removing the need to load json.js. How is toJSONString() any different from toSource()? http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Global_Objects:Object:toSource -- Lachlan Hunt http://lachy.id.au/
