Re: [whatwg] Thoughts on HTML 5
2008/12/21 Garrett Smith dhtmlkitc...@gmail.com Styling is done in css. Dynamic styling is currently done with the style property of HTMLElement. This is currently implemented in DOM2HTML and HTML5, but I once read they're going to write a separate CSS-Object Model, whose spec is not ready yet, but it is mentioned in the CSS current work. I don't have time to go into the all the problems with CSSOM here. Shortcomings of the CSSOM 'views' module were discussed on www-style. 'VIews' is not the only CSSOM module that has problems. Most of CSS is already implemented (like HTML, they're just standarizing what browser already do) you don't need collection either: just use appropriate DOMNodeLists, while for DOMStringMap you may use binding specific features (all Object are hash maps in ECMAScript3): it works this way even in HTML5 Where are you getting this information? What information? a) DOMNodeList are collection of ordered Nodes -- see DOM3Core for definition - if you want only Element Nodes see the Element Traversal specification by the WebApps WG b) ECMAScript Object are implemented as associative arrays (hash map / binary tree) -- see Mozilla Developer Center: it is only about Firefox, but I think all browser behave like this since they must reference arbitrary properties that are not known at compile time (if they compile) c) DOMStringMap is defined to be like ECMAScript Object -- look at its IDL: it has no members, no properties, no methods but scripts use certain features only on their own browsing context, so that may be moved from that to global scope, removing the whole window object from scope (for current javascript you can write window.window.window.window.window... and get the same as nothing) The closest definition to 'nothing' would be the value undefined. I do not know of a browser where - window.window.window === undefined is true by default. I get window. a) undefined != undefined is true in ECMAScript b) i didn't mean undefined, i mean literally nothing, eg this script window.window.window.window.window.window.window.alert(hello, world); is exactly the same as alert(hello, world); The closes thing we got to an example of invalid html is TJ post about jquery validation plugin. If you click throuh, there is an demo using a minlength custom attribute. The attribute may have the effect the author wanted it to have in a set of browses he is concerned about. That effect and the set of browsers could be more clearly demonstrated in an example that shows only that, as well as edge cases where results may vary. I don't see your point... If you can't define clearly what can be reasonably expected of a piece of (invalid) code, then nothing can be reasonably expected of it. It's not a good to write code that can't have an expected outcome. HTML5 is here to define what browser must and must not do with de-facto standards (called DOM Level 0, but also features that once were browser-specific like embed) Instead what I'm asking is only for the developer point of view. Giovanni
Re: [whatwg] Thoughts on HTML 5
Ian Hickson schrieb: Deprecating HTML thus seems like vain effort. (We already tried over the past few years with XHTML 1.x, and it didn't work.) I'd say it _did_ work. :-) Philipp Kempgen
Re: [whatwg] Thoughts on HTML 5
Am Sonntag, den 21.12.2008, 17:54 +0100 schrieb Philipp Kempgen: Ian Hickson schrieb: Deprecating HTML thus seems like vain effort. (We already tried over the past few years with XHTML 1.x, and it didn't work.) I'd say it _did_ work. :-) I'd say too: The worst abominations have disappeared (for new sites, that is). the font element, for example, or frames through deprecating them. Fact: Deprecating stuff takes it out of (X)HTML-Books, Howtos like Selfhtml warn against it, thus ensuring lesser use by novices. Does anyone remember marquee ? Cheers -- Nils Dagsson Moskopp http://dieweltistgarnichtso.net
Re: [whatwg] Thoughts on HTML 5
Please Note: all the following is my personal humble opinion. As I discovered lately, the main problem of HTML5 is its design oriented to keep features that are distributed across browsers, that work or that are simple way to solve big problem. Actually, they are a bunch of different features somehow not integrated to the others. Instead, programmer (please note, I use the word programmer, not author or web designer) developing *new* application may more like a more structured and logical organization, like XHTML modularization is. HTML5 features, summed in big groups, are (in spec order): 1) common syntax for the most used datatypes. 2) additional DOM interfaces, which include HTMLElement - HTMLCollection - HTMLFormsControlCollection - HTMLOptionsCollection - DOMTokenList - DOMStringMap 3) Elements and Content Models 4) Element types: metadata - structure - sectioning - grouping - text - editing - embedding - table - forms - interactive - scripting elements 5) User agent requirements 6) User Interaction 7) Communication 8) HTML Syntax Some of these features can be achieved without any of HTML5, for example 1) use XMLSchema datatypes 2) you don't need HTMLElement: markup insertion, attributes querying can be done using DOM3Core (that in latest browser are even more performant as no parser is involved), events are far better handled by DOM3Events, styling is included by CSSOM you don't need collection either: just use appropriate DOMNodeLists, while for DOMStringMap you may use binding specific features (all Object are hash maps in ECMAScript3): it works this way even in HTML5 3) use XHTML2, which is extensible because modularized 4) metadata is better handled by XHTML2 Meta Attributes module, which fully integrates the RDF module in any elements; structure, sectioning, grouping are the same; text is very similar: you don't have time, but you can have span datatype=xsd:date content=2008-12-21Today/span as in HTML5 you have time value=2008-12-21Today/time; for progress and meter semantic you can use role attribute (for styling you always use CSS); editing is the same, but you have an attribute instead of an element, so you don't have the issue that ins and del can contain everything, even a whole document (not including html); embedding is much more powerful as any element can be replaced by embedded content; tables are the same (you don't have tables API; but you can still use DOM3Core); XForms are actually more powerful than WebForms2, since you divide presentation from data from action (that is implemented declaratively); interactive elements are not needed at all: details is better implemented as it is now (ECMAScript3 + CSS3), datagrid is just a way to put data in a tree model: use plain XML for that; command and a in XHTML2 implemented in any element using href attribute; menu is mostly an ul with some style; scripting uses XMLEvents and handler: it looks the same, but it is different as it is more event oriented (scripts are not executed by default, they're executed when some event fires) 8) HTML syntax: as I said before, use XML for that There are instead features that are indeed very useful to develop a web application, but are not achievable using other means that HTML5: 1) some way to interact with object (please note: object, not embed: object is for plugins, embed for content) : actually this can be done using something like cross document messaging, assuming that object creates a new browsing context (it already does if the target is text/html or application/xhtml+xml), but we need a specification for message syntax 2) the binding specific global scope (that is, what object are available in all scopes, if binding supports this); this is normally the window object, but scripts use certain features only on their own browsing context, so that may be moved from that to global scope, removing the whole window object from scope (for current javascript you can write window.window.window.window.window... and get the same as nothing) 3) the Window object (which includes window name, window location, cross document messaging, dialog windows) 4) Protocol and Content Handlers 5) Session and Local storage 6) Database storage 7) Drag and Drop 8) WebSockets What I am asking now is so to modularize HTML. copy those features into separate, interoperable modules, removing legacy features (like window.on-whatever event listener) A copy of those will remain in HTML5, because browser implement them at the moment, and the HTML5 goal is that all browser implement the same things in the same ways Instead, some web developers in the future will think that a modularized and less redudant API is more usable, like I personally do, and switch to that, without mixing with HTML5: actually, I guess what a Database API does inside HTML. Best regards, Giovanni Campagna
Re: [whatwg] Thoughts on HTML 5
Hi Giovanni, I haven't read your entire comment, but with your point eight will break backwards compatibility. As far as I know is HTML5 supposed to combine old and new. The problem with interfaces is that you can not simply change them. That's just a fact we have to deal with. jorgen On Dec 21, 2008, at 7:12 PM, Giovanni Campagna wrote: Please Note: all the following is my personal humble opinion. As I discovered lately, the main problem of HTML5 is its design oriented to keep features that are distributed across browsers, that work or that are simple way to solve big problem. Actually, they are a bunch of different features somehow not integrated to the others. Instead, programmer (please note, I use the word programmer, not author or web designer) developing *new* application may more like a more structured and logical organization, like XHTML modularization is. HTML5 features, summed in big groups, are (in spec order): 1) common syntax for the most used datatypes. 2) additional DOM interfaces, which include HTMLElement - HTMLCollection - HTMLFormsControlCollection - HTMLOptionsCollection - DOMTokenList - DOMStringMap 3) Elements and Content Models 4) Element types: metadata - structure - sectioning - grouping - text - editing - embedding - table - forms - interactive - scripting elements 5) User agent requirements 6) User Interaction 7) Communication 8) HTML Syntax Some of these features can be achieved without any of HTML5, for example 1) use XMLSchema datatypes 2) you don't need HTMLElement: markup insertion, attributes querying can be done using DOM3Core (that in latest browser are even more performant as no parser is involved), events are far better handled by DOM3Events, styling is included by CSSOM you don't need collection either: just use appropriate DOMNodeLists, while for DOMStringMap you may use binding specific features (all Object are hash maps in ECMAScript3): it works this way even in HTML5 3) use XHTML2, which is extensible because modularized 4) metadata is better handled by XHTML2 Meta Attributes module, which fully integrates the RDF module in any elements; structure, sectioning, grouping are the same; text is very similar: you don't have time, but you can have span datatype=xsd:date content=2008-12-21Today/span as in HTML5 you have time value=2008-12-21Today/time; for progress and meter semantic you can use role attribute (for styling you always use CSS); editing is the same, but you have an attribute instead of an element, so you don't have the issue that ins and del can contain everything, even a whole document (not including html); embedding is much more powerful as any element can be replaced by embedded content; tables are the same (you don't have tables API; but you can still use DOM3Core); XForms are actually more powerful than WebForms2, since you divide presentation from data from action (that is implemented declaratively); interactive elements are not needed at all: details is better implemented as it is now (ECMAScript3 + CSS3), datagrid is just a way to put data in a tree model: use plain XML for that; command and a in XHTML2 implemented in any element using href attribute; menu is mostly an ul with some style; scripting uses XMLEvents and handler: it looks the same, but it is different as it is more event oriented (scripts are not executed by default, they're executed when some event fires) 8) HTML syntax: as I said before, use XML for that There are instead features that are indeed very useful to develop a web application, but are not achievable using other means that HTML5: 1) some way to interact with object (please note: object, not embed: object is for plugins, embed for content) : actually this can be done using something like cross document messaging, assuming that object creates a new browsing context (it already does if the target is text/html or application/xhtml+xml), but we need a specification for message syntax 2) the binding specific global scope (that is, what object are available in all scopes, if binding supports this); this is normally the window object, but scripts use certain features only on their own browsing context, so that may be moved from that to global scope, removing the whole window object from scope (for current javascript you can write window.window.window.window.window... and get the same as nothing) 3) the Window object (which includes window name, window location, cross document messaging, dialog windows) 4) Protocol and Content Handlers 5) Session and Local storage 6) Database storage 7) Drag and Drop 8) WebSockets What I am asking now is so to modularize HTML. copy those features into separate, interoperable modules, removing legacy features (like window.on-whatever event listener) A copy of those will remain in HTML5, because browser implement them at the moment, and the HTML5 goal is that all browser
Re: [whatwg] Thoughts on HTML 5
On 21/12/08 17:22, Nils Dagsson Moskopp wrote: Am Sonntag, den 21.12.2008, 17:54 +0100 schrieb Philipp Kempgen: Ian Hickson schrieb: Deprecating HTML thus seems like vain effort. (We already tried over the past few years with XHTML 1.x, and it didn't work.) I'd say it _did_ work. :-) I'd say too: The worst abominations have disappeared (for new sites, that is). thefont element, for example, or frames through deprecating them. You're assuming that's an indication of the power of specifications rather than of actual advantages to using CSS or avoiding frames. What mostly failed, and which Hixie is referring to, was the attempt to move the web from a tag soup (text/html) basis to an XML (application/xhtml+xml) basis. Perhaps that's because the advantages of the later were not persuasive. As I've argued elsewhere in the thread, there's money in staying with text/html. Does anyone remembermarquee ? That's a bad example. MARQUEE was never standardized in a specification, so it was never possible to deprecate it. -- Benjamin Hawkes-Lewis
Re: [whatwg] Thoughts on HTML 5
On Sun, Dec 21, 2008 at 10:12 AM, Giovanni Campagna scampa.giova...@gmail.com wrote: Please Note: all the following is my personal humble opinion. parser is involved), events are far better handled by DOM3Events, styling is included by CSSOM Styling is done in css. I don't have time to go into the all the problems with CSSOM here. Shortcomings of the CSSOM 'views' module were discussed on www-style. 'VIews' is not the only CSSOM module that has problems. you don't need collection either: just use appropriate DOMNodeLists, while for DOMStringMap you may use binding specific features (all Object are hash maps in ECMAScript3): it works this way even in HTML5 Where are you getting this information? but scripts use certain features only on their own browsing context, so that may be moved from that to global scope, removing the whole window object from scope (for current javascript you can write window.window.window.window.window... and get the same as nothing) The closest definition to 'nothing' would be the value undefined. I do not know of a browser where - window.window.window === undefined is true by default. I get window. A relevant example would be useful. The closes thing we got to an example of invalid html is TJ post about jquery validation plugin. If you click throuh, there is an demo using a minlength custom attribute. The attribute may have the effect the author wanted it to have in a set of browses he is concerned about. That effect and the set of browsers could be more clearly demonstrated in an example that shows only that, as well as edge cases where results may vary. If you can't define clearly what can be reasonably expected of a piece of (invalid) code, then nothing can be reasonably expected of it. It's not a good to write code that can't have an expected outcome. Best regards, Giovanni Campagna
Re: [whatwg] Thoughts on HTML 5
2008/12/17 Ian Hickson i...@hixie.ch This doesn't cost any time in HTML either, since the tokeniser doesn't need to worry about what tags have end tags, the tree construction side just drops unexpected end tags on the floor. I don't think authors expect tags to disappear. don't check for insertion modes Having an insertion mode isn't particularly a performance cost. (It affects code footprint, but that's about it.) 1) it needs more code (one x insertion mode): more code is always less performance, even if it is just to load a bigger executable 2) it needs code to select the insertion mode for the next element (when the spec says to reset the insertion mode): in the worst case it has to compare nodeName 18 times That's the same as HTML. No it is not. HTML defines special beaviour for the following elements: address, area, article, aside, base, basefont, bgsound, blockquote, body, br, center, col, colgroup, command, datagrid, dd, details, dialog, dir, div, dl, dt, embed, eventsource fieldset, figure, footer, form, frame, frameset, h1, h2, h3, h4, h5, h6, head, header, hr, iframe, img, input, isindex, li, link, listing, menu, meta, nav, noembed, noframes, noscript, ol, p, param, plaintext, pre, script, section, select, spacer, style, tbody, textarea, tfoot, thead, title, tr, ul, and wbr. I think they're quite too many to say that it is like XML There are a number of HTML5 parser implementations, and data suggests that there is no particular performance gain. There are no actual HTML5 parser implementation, only HTML4 compatible with new syntax. (are you sure that closed source browsers really do what is written in the specification?) There's no guessing in HTML either; all input streams have very specific and required results. Actually, there's nothing that really says that divpsome text/ppsome more text/p/div is more correct than divpsome textpsome more text/p/p/div Just when writing the specification you guess that the first possibility is what auctor thought. You are guessing, not the browser. Validating code is certainly an important QA point, but once you've shipped code, the presence of an error is not helpful to the end user. Often errors in XML files weren't present when the file was created, but appear later when new text is merged in automatically. As Nils pointed, it is an error itself to have any content to be automatically merged inside a stream. It is like opening a random file, executing it and expecting no errors. Every input, even from the most trustworthy source, must be parsed for errors and then checked after publishing. And if an end user finds an error, he probably will report it to the owner of the web site, who in turn will report it (quite angrily) to web designer. Something like: What on earth are you doing in front of the coffe machine? I don't pay you to rest! Fix that website immediately! Well, they've ignored it for the past 7 years, so why would they change? Nobody said to user that he was browsing a deprecate web site. If something like IE7 information bar (ie. a non modal bar, disactivable and not annoying the user, but immediately visible) could appear in a web site sent with text/html, I think companies won't like their site tagged as deprecate and port them to application/xhtml+xml in no time (do you imagine what deprecate can mean on news web site?) And don't forget that the most common browser was IE6, not very standard oriented... Anyway, it isn't clear that we would _want_ to deprecate HTML, even if we had any real choice in the matter. I'm not sure if I understood your sentence (sorry, English is not my mother language). Anyway, you just have to put an authoring requirement for text/html 1) user agent will just ignore it and implement the HTML algorithm (we don't want to break the web, using Microsoft terms) 2) standard-oriented authors will convert their sites to application/xhtml+xml (if they didn't before) 3) other authors will keep their tag soup (and get their sites yellow-barred) 4) company owners will make their decision between 2 and 3 Gradually, n° 3 will disappear, because there's no actual needing for HTML. @ Garret: originally I wrote XBL2, then I deleted it since it was not pertinent (and went in opposite direction as my opinion), but i forgot to edit list number. Secondly, what do you mean with bubbling? Ok, I can put an event handler on what I need on, say, HTML, but then how can I execute the proper handler? I must retrieve it, either attaching it to the DOM node (but I don't advice it, it is not interoperable) or maintaing an hash map with class names / function pointers and solve it. Actually, there is no performant and clean solution, just few hacks.
Re: [whatwg] Thoughts on HTML 5
Giovanni Campagna wrote: 2008/12/17 Ian Hickson i...@hixie.ch This doesn't cost any time in HTML either, since the tokeniser doesn't need to worry about what tags have end tags, the tree construction side just drops unexpected end tags on the floor. I don't think authors expect tags to disappear. Perhaps (got any actual evidence about author expectations in this case?), but that's not a problem for tokenizer performance. You're shifting the goalposts. Anyway, if we're talking authorial expectations, ordinary authors don't expect a href=http://example.com?foobarbaz; to be an unrecoverable error, but it is in XHTML. It's not like either of these syntaxes make sense to ordinary people or were even intended to do so. The original authoring model for HTML was supposed to be paragraph and anchor, mediated by some sort of vaguely WYSIWYG type editor, not angle-bracketed tags. don't check for insertion modes Having an insertion mode isn't particularly a performance cost. (It affects code footprint, but that's about it.) 1) it needs more code (one x insertion mode): more code is always less performance, even if it is just to load a bigger executable 2) it needs code to select the insertion mode for the next element (when the spec says to reset the insertion mode): in the worst case it has to compare nodeName 18 times That's the same as HTML. No it is not. HTML defines special beaviour for the following elements: address, area, article, aside, base, basefont, bgsound, blockquote, body, br, center, col, colgroup, command, datagrid, dd, details, dialog, dir, div, dl, dt, embed, eventsource fieldset, figure, footer, form, frame, frameset, h1, h2, h3, h4, h5, h6, head, header, hr, iframe, img, input, isindex, li, link, listing, menu, meta, nav, noembed, noframes, noscript, ol, p, param, plaintext, pre, script, section, select, spacer, style, tbody, textarea, tfoot, thead, title, tr, ul, and wbr. I think they're quite too many to say that it is like XML There are a number of HTML5 parser implementations, and data suggests that there is no particular performance gain. There are no actual HTML5 parser implementation, only HTML4 compatible with new syntax. Ahem, there are several: http://www.google.com/search?q=html5+parser There's no guessing in HTML either; all input streams have very specific and required results. Actually, there's nothing that really says that divpsome text/ppsome more text/p/div is more correct than divpsome textpsome more text/p/p/div Just when writing the specification you guess that the first possibility is what auctor thought. You are guessing, not the browser. A conforming browser will interpret the markup as specified by the specification, so there is no difference. Every input, even from the most trustworthy source, must be parsed for errors and then checked after publishing. In practice, people find this very hard for XML and most web publishing systems (WordPress etc.) don't work like this even if they should. Also, much of the web is ad-supported. The ads ecosystem is based around including markup from trusted sources. Those including the markup are generally not able to exert much control over the included markup, even when they are some of the biggest publishers on the web. Getting ads to have user-friendly HTML (e.g. alt attributes for image links) is nigh impossible; trying to get conforming HTML is a wet dream; and trying to get ads in valid XML is a likely to be a complete non-starter. Why would an ad creator bother, when they could choose a different partner and use their old text/html ads? And if an end user finds an error, he probably will report it to the owner of the web site, who in turn will report it (quite angrily) to web designer. Something like: What on earth are you doing in front of the coffe machine? I don't pay you to rest! Fix that website immediately! Probably - got any empirical evidence for that? I don't usually report errors in websites I visit (even _I_ usually have other things to do with my time). In any case, avoiding angry customers complaining because XML threw a fatal error that would have been handled gracefully in HTML is an infinitely stronger incentive for developers to keep using text/html than anything the spec might say on the matter, so this isn't a persuasive argument for switching to application/xhtml+xml. Well, they've ignored it for the past 7 years, so why would they change? Nobody said to user that he was browsing a deprecate web site. If something like IE7 information bar (ie. a non modal bar, disactivable and not annoying the user, but immediately visible) could appear in a web site sent with text/html, I think companies won't like their site tagged as deprecate and port them to application/xhtml+xml in no time (do you imagine what deprecate can mean on news web site?) Indeed, they would be upset. And they
Re: [whatwg] Thoughts on HTML 5
2008/12/18 Benjamin Hawkes-Lewis bhawkesle...@googlemail.com Perhaps (got any actual evidence about author expectations in this case?), but that's not a problem for tokenizer performance. You're shifting the goalposts. My comment about tokenizer performance was later. By the way, author should not expect that invalid markup work in any particular way (in the past they did and wrote specific markup for specific implementation) Anyway, if we're talking authorial expectations, ordinary authors don't expect a href=http://example.com?foobarbaz; to be an unrecoverable error, but it is in XHTML. authors didn't expect that example.com?foobarsection=1 became example.com?foobar§ion=1 but this happened in Netscape and IE quite long ago if they got an error, at least they knew that it was not a correct syntax and should have been avoided, since it could lead to different results in different browsers (it is not valid HTML, btw) It's not like either of these syntaxes make sense to ordinary people or were even intended to do so. The original authoring model for HTML was supposed to be paragraph and anchor, mediated by some sort of vaguely WYSIWYG type editor, not angle-bracketed tags. If you don't like like less-than and greater-than (it is not Unicode angle bracket actually), publish your work in PDF or DOC. HTML stays for HyperText Markup Language. Markup (i.e. tags) can't be removed. A conforming browser will interpret the markup as specified by the specification, so there is no difference. Yes, the fact is that the specification itself guesses what an average author thinks when it writes HTML In practice, people find this very hard for XML and most web publishing systems (WordPress etc.) don't work like this even if they should. Why do SQL injections or buffer overrun attacks happen? Because applications don't check for input. The same for XML: you check, you're sure nobody will try to take your site down. You don't check, that's your fault. Also, much of the web is ad-supported. The ads ecosystem is based around including markup from trusted sources. Those including the markup are generally not able to exert much control over the included markup, even when they are some of the biggest publishers on the web. Getting ads to have user-friendly HTML (e.g. alt attributes for image links) is nigh impossible; trying to get conforming HTML is a wet dream; and trying to get ads in valid XML is a likely to be a complete non-starter. Why would an ad creator bother, when they could choose a different partner and use their old text/html ads? If ad buyer refuses to buy a non-valid-XML ad, probably the ad creator will rewrite them. Probably - got any empirical evidence for that? I don't usually report errors in websites I visit (even _I_ usually have other things to do with my time). If any error prevents someone from correctly browsing that page, he first reports that to web owner, then to browser creator. Indeed, they would be upset. And they might even try porting it. However, there's little incentive for browser makers to throw information bars over the majority of the existing web just to assuage your desire for people to switch to XML. In fact, there are disincentives for browser vendors to include such an information bar since: 1. Users will complain about error messages about sites that have always worked just fine. (I'm switching back to IE8.) 2. Users will be trained to ignore error messages since sites work just fine even with a finger-wagging information bar slapped across the top, which is a security risk. Even persuading browser vendors to include an indication of whether a website is valid or not has been a non-starter for every browser except iCab - and even iCab has dropped that indication in the latest version. If an user complains about a warning (not error) indication, he can disable it (but not security errrors). On the other hand, some user will complain with the site creator, instead of with the browser creator. Ian was effectively asking: Why deprecate text/html? You appear to be trying to answer: How would we deprecate text/html? which is a different question (and I've indicated some problems with your suggestion above). Sorry, I didn't understand (it looked like we want to deprecate html but we don't have instruments, but it didn't make much sense). Except on the ad-supported web… 1) use iframe 2) use object 3) use embed 4) use img 5) use well-formed XHTML 6) use JS + DOM Do you think it is enough? Giovanni Campagna
Re: [whatwg] Thoughts on HTML 5
2008/12/16 Ian Hickson i...@hixie.ch I tried following this thread but I can't find what I would need to change in the spec to address the feedback so far. If this feedback relates to requests for the spec, please elaborate on exactly what it is that should change -- thanks! I thought later on this topic and i arrived to conclusion that we cannot forbid or delete completely the HTML serialization, but there are no real use cases for this in server generated web pages. Even in case of user-generated content an application must parse it server-side prior to publish, and in the worst case may use the spec's algorithm to build a standard-compliant DOM tree, then serialize it producing valid XML code (therefore an application can always provid valid XHTML) In my opinion, we should allow content to be sent as text/html, but HTML serialization and associated technologies (DOMDocument.write or DOMElement.outerHTML) should be marked deprecate, since there are stricter and more performant way to do same thing. Giovanni Campagna
Re: [whatwg] Thoughts on HTML 5
On Wed, 17 Dec 2008, Giovanni Campagna wrote: I thought later on this topic and i arrived to conclusion that we cannot forbid or delete completely the HTML serialization, but there are no real use cases for this in server generated web pages. Even in case of user-generated content an application must parse it server-side prior to publish, and in the worst case may use the spec's algorithm to build a standard-compliant DOM tree, then serialize it producing valid XML code (therefore an application can always provid valid XHTML) In my opinion, we should allow content to be sent as text/html, but HTML serialization and associated technologies (DOMDocument.write or DOMElement.outerHTML) should be marked deprecate, since there are stricter and more performant way to do same thing. XML is neither more performant nor stricter than XML. The main differences are that XML has less user-friendly error recovery and supports arbitrary namespaces. Authors have clearly indicated that this is not compelling. Deprecating HTML thus seems like vain effort. (We already tried over the past few years with XHTML 1.x, and it didn't work.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Thoughts on HTML 5
2008/12/17 Ian Hickson i...@hixie.ch XML is neither more performant nor stricter than XML. The main differences are that XML has less user-friendly error recovery and supports arbitrary namespaces. Authors have clearly indicated that this is not compelling. Deprecating HTML thus seems like vain effort. (We already tried over the past few years with XHTML 1.x, and it didn't work.) I don't write browser code, honestly, but I think that XML parser don't need to check for attribute types (they're all quoted strings), don't check for element type (whether there can or must be closing tag), don't check for insertion modes, just parses the input completely any semantic or particular behaviour associated with any tag. Then, when the DOMElement or DOMAttr or DOM-whatever are built, they get the appropriate interface (eg. HTMLElement) depending on the namespace. I think that the latter algorithm can be faster, but I actually haven't got any benchmark (I cannot have, since no browser implements completely HTML5 parse algorithm yet). Secondly, stricter to me means: every warning is an error. Look in the following code: divpsome text/div When the HTML parser find char 'd', i can imagine it expects char 'p' (as in /p) and fallback to quirk mode otherwise, although no assertion are made in the official HTML spec. When parsing as XML, though, the parser can simply get the char: is it a 'p'? then go forward, else stop parsing no quirks, no trying to guess author intentions what about divpsome textpsome more text/div? is it this: divpsome text/ppsome more text/p/div or either this: divpsome textpsome more text/p/p/div And most of time strict checking means less errors caused by distraction (misspelling of an end tag, missing '/' when self-closing elements not always selfclosing, etc.) Lastly, you said that deprecating HTML is vain. Well, IMO, if you deprecate it now, maybe this year, or next year, or even the year after, nothing will move. But (according to WHATWG Wiki) HTML spec will be ready in 2020. Do you think that in 12 years everybody will just ignore the string HTML is deprecated and should no longer be used? By the way, XHTML1.0 / 1.1 said nothing about HTML4, they were independent specifications. Giovanni Campagna
Re: [whatwg] Thoughts on HTML 5
On Wed, 17 Dec 2008, Giovanni Campagna wrote: I don't write browser code, honestly, but I think that XML parser don't need to check for attribute types (they're all quoted strings), XML parsers still have to check for quotes ( vs '), which takes no less time than HTML's checking for quotes ( vs ' vs nothing). don't check for element type (whether there can or must be closing tag), This doesn't cost any time in HTML either, since the tokeniser doesn't need to worry about what tags have end tags, the tree construction side just drops unexpected end tags on the floor. don't check for insertion modes Having an insertion mode isn't particularly a performance cost. (It affects code footprint, but that's about it.) just parses the input completely any semantic or particular behaviour associated with any tag. Then, when the DOMElement or DOMAttr or DOM-whatever are built, they get the appropriate interface (eg. HTMLElement) depending on the namespace. That's the same as HTML. I think that the latter algorithm can be faster, but I actually haven't got any benchmark (I cannot have, since no browser implements completely HTML5 parse algorithm yet). There are a number of HTML5 parser implementations, and data suggests that there is no particular performance gain. Secondly, stricter to me means: every warning is an error. Look in the following code: divpsome text/div When the HTML parser find char 'd', i can imagine it expects char 'p' (as in /p) and fallback to quirk mode otherwise, although no assertion are made in the official HTML spec. Not at all, the /p is completely optional in HTML, so that's not a problem. Also, it doesn't switch to quirks mode. The HTML5 spec defines how to handle these cases in excruciating detail. When parsing as XML, though, the parser can simply get the char: is it a 'p'? then go forward, else stop parsing no quirks, no trying to guess author intentions There's no guessing in HTML either; all input streams have very specific and required results. what about divpsome textpsome more text/div? is it this: divpsome text/ppsome more text/p/div Both of those are valid. or either this: divpsome textpsome more text/p/p/div All three of these have very well-defined results. There's no ambiguity or guessing involved. And most of time strict checking means less errors caused by distraction (misspelling of an end tag, missing '/' when self-closing elements not always selfclosing, etc.) Validating code is certainly an important QA point, but once you've shipped code, the presence of an error is not helpful to the end user. Often errors in XML files weren't present when the file was created, but appear later when new text is merged in automatically. Lastly, you said that deprecating HTML is vain. Well, IMO, if you deprecate it now, maybe this year, or next year, or even the year after, nothing will move. But (according to WHATWG Wiki) HTML spec will be ready in 2020. Do you think that in 12 years everybody will just ignore the string HTML is deprecated and should no longer be used? Well, they've ignored it for the past 7 years, so why would they change? By the way, XHTML1.0 / 1.1 said nothing about HTML4, they were independent specifications. They were positioned as replacements. Anyway, it isn't clear that we would _want_ to deprecate HTML, even if we had any real choice in the matter. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Thoughts on HTML 5
On Tue, Dec 16, 2008 at 5:14 AM, Giovanni Campagna scampa.giova...@gmail.com wrote: Maybe so-called invalid HTML attributes are not the only solution, but in my opinion it is a simple way to embed metadata within any element. Imagine that such markup is then passed to a web application through XHR. In that case scripts aren't parsed and executed. In this case you have three ways to attach a behaviour: 2) on-event standard attributes (but they not performant since they're parsed every time the event fires and the cannot include chars like or , they need to be escaped) 3) assigning a class and some metadata using data-, then getElementsByClassName and addEventListener What is the first way? I usually prefer to use bubbling. If the callback has an event target that it is interested in, it can deal with it at that time. Garrett
Re: [whatwg] Thoughts on HTML 5
Am Dienstag, den 16.12.2008, 14:22 + schrieb Philip Taylor: On Tue, Dec 16, 2008 at 2:15 PM, Nils Dagsson Moskopp nils-dagsson-mosk...@dieweltistgarnichtso.net wrote: As I said, invalid input should be rejected in the first place. When I write a blog post, I usually catch errors like this when I click on the preview button and its all yellow. But you still accept user input that can lead to ill-formed output, like in http://blog.dieweltistgarnichtso.net/?s=%ef%bf%bf :-) (That particular case probably doesn't affect anyone other than the user who enters that URL, but it's a pain whenever the user input is displayed back to other users or shown in admin interfaces, and very few people seem to implement it correctly in practice.) Please, its Wordpress ! Those are the people that use eval() when parsing input. I already have hacked a bit and will no doubt do something about input as soon as my HTML5 theme based on sandbox is ready. In the meantime, don't input this character in the comments, I've not really thrilled to see that stuff implode. Oh and btw, my own web app *will* reject input and / or normalize it (whenever it is done, with which I mean: I first have to sort out some issues with the database ...). Greetings -- Nils Dagsson Moskopp http://dieweltistgarnichtso.net
Re: [whatwg] Thoughts on HTML 5
On Mon, Dec 15, 2008 at 8:36 PM, Garrett Smith dhtmlkitc...@gmail.com wrote: On Mon, Dec 15, 2008 at 8:02 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: You're not Nicholas. We don't know if that is what Nicholas expects his HTML to do or if he is expecting something else. In absence of an example, I can't do much more than guess. I cannot expect your assumptions to be correct. Well, of course, but you sent the message to the entire group, so you should be ready for answers from the whole group. ^_^ You've not stated how creating invalid HTML can control scripts. Having an interest in scripting, I would like to know how this works. Dude, come on. You're trying to poison the dialogue here. The point Instead of a complaining about my intentions, why don't you post an example that shows the problem (demonstrate need), how the problem is overcome (the invalid HTML solution), and what browsers actually do? Sorry, I thought I was demonstrating it, but I guess I was being too general. An example I know of off the top of my head is the jQuery Validation plugin[1]. If you can uniquely identify the elements in your form (either through #id or other structural means) and can place scripts (not always possible for end-users of a CMS application or something), you can tell the plugin exactly how to validate each form element when you first invoke it, through the script. If either of these are false, though, you can instead place the attributes on the element itself, and the script will read them off while it's executing. Many of the common ones can be easily and usefully embedded in @class (giving an element a class of required, frex, can also help with styling), but using the more complex validation routines in @class requires you to embed JSON, which is a horrible hack (as the parser doesn't recognize this and just tokenizes it as multiple oddly named classes). The script reads the entire class attribute as a string and parses this effectively, but it can have unintended consequences. Instead, you can embed these more complex routines in custom attributes. jQuery has a plugin that allows easy access to these in a cross-browser way (the Metadata plugin[2]). Doing this allows you to embed complex validation instructions on the elements themselves in an easily human-readable and human-writable format, with an absolute minimum of side-effects (generally, *no* side effects). I've seen code that has invalid attributes. These attributes won't always have the same effect as the author wanted them to. Not all authors expect the same thing from their invalid HTML. Recent c.l.js discussions have included examples of page author using a named element where that element does not support the name attribute, e.g. span name='fred'. The author had expected the element to be included with getElementsByName, but it wasn't. (not the first time someone has expected nonstandard behavior from an attribute). I've seen other uses of invalid HTML that did what the author wanted to in most cases. This is (one reason) why I objected to using the blanket term invalid HTML, because it covers far more than what we're talking about here. *I*, and Nicholas I'm sure, are referring solely to using *custom* attributes. In this example, you're talking about hacking an existing attribute, and being surprised at the outcome. (I find it likely that the author was trying to use @name as a replacement for @class, hoping to lean on the already-implemented getElementsByName function rather than rolling his own getElementByClass). As to how custom attributes can help control scripts, look into any decent javascript plugin. Many of them utilize some form of metadata What is a javascript plugin? The param element is designed for associating data with a plugin, such as a swf movie. Is this an allusion? I apologize; I thought the term was widespread enough. When using things like the jQuery library, additional scripts built on top of it are termed 'plugins'. In general, though, the case for custom attributes is identical to the case for JS expando attributes, which *have* been around for a long time. It can be very useful for a script to store arbitrary data on an element, and the simplest way to do this in many cases is by creating a new expando attribute. Custom attributes is nothing more than a way to embed this information in the static HTML as well, so that it can be authored and carried around independently of the script, or provide good 'initial values' to the script. And again, as stated previously, this discussion *has* already been settled. We have the data-* attributes as an officially blessed way to provide custom attributes on HTML, and as a recommended way to add expando attributes via JS. What I'm talking about is only 'invalid HTML' in HTML4 - it's perfectly valid html5 now. 1: http://bassistance.de/jquery-plugins/jquery-plugin-validation/ 2:
Re: [whatwg] Thoughts on HTML 5
2008/12/16 Nils Dagsson Moskopp nils-dagsson-mosk...@dieweltistgarnichtso.net Am Dienstag, den 16.12.2008, 14:32 +0100 schrieb Giovanni Campagna: (The same behaviour can be achieved also with a @namespace rule, putting non-standard attributes in an application-specific namespace) Since data attributes do not exist as of yet, I believe people would use XML for namespaces, so I somehow don't see your problem. 1) data attributes are not standarized and the dataset DOMStringMap is not present, but if you try using them with domCore interfaces they should work (i haven't tested though) 2) XML serialization is much more difficlut to implement than old HTML, and, as i said before, in many cases it is not implementable at all: probably a company which hosts user-generated content such as blogs or forums won't like that no browser can display his pages because someone wrote invalid html even the most experienced can mis-type code, and in that case the only way to solve is to manually edit source using a plain text editor, which is not possible with user-generated content 3) the dataset DOMStringMap is a quite useful way to enumerate attributes explicitly marked as application data
Re: [whatwg] Thoughts on HTML 5
Am Dienstag, den 16.12.2008, 14:32 +0100 schrieb Giovanni Campagna: (The same behaviour can be achieved also with a @namespace rule, putting non-standard attributes in an application-specific namespace) Since data attributes do not exist as of yet, I believe people would use XML for namespaces, so I somehow don't see your problem. -- Nils Dagsson Moskopp http://dieweltistgarnichtso.net
Re: [whatwg] Thoughts on HTML 5
Am Dienstag, den 16.12.2008, 15:38 +0100 schrieb Giovanni Campagna: Browser assume that author knows XML because he's put an application/* +xml mime type. On the other hand, this assumption cannot be done for blogger, who aren't expected to know XML / XML 1.1 / XHTML 1.0 / HTML5 specs (they're not expected to know about what or w3c either) Then they shouldn't write XHTML in the first place ... there *are* some good autoformatters which handle stuff for you (think: newline - br/, two newlines - paragraph). Also, WYSIWYG editors should *not* gave you the oppontuniy to mess up your code. Could not save you post, invalid XML markup (Mismatched end tag, expecting img, found /p) See W3C XML1.1 specification (link to XML spec) for further information about this. Or just Not well-formed (attribute values must be encoded in double quotes) The current error messages are crap, that is totally right. They could certainly be more user-friendly. You have no page, thus no way to edit! The admin interface should be always well-formed, having the offending portion in a textarea (or similar) for easy editing and an iframe for viewing. -- Nils Dagsson Moskopp http://dieweltistgarnichtso.net
Re: [whatwg] Thoughts on HTML 5
2008/12/16 Nils Dagsson Moskopp nils-dagsson-mosk...@dieweltistgarnichtso.net Am Dienstag, den 16.12.2008, 15:38 +0100 schrieb Giovanni Campagna: Browser assume that author knows XML because he's put an application/* +xml mime type. On the other hand, this assumption cannot be done for blogger, who aren't expected to know XML / XML 1.1 / XHTML 1.0 / HTML5 specs (they're not expected to know about what or w3c either) Then they shouldn't write XHTML in the first place ... there *are* some good autoformatters which handle stuff for you (think: newline - br/, two newlines - paragraph). Also, WYSIWYG editors should *not* gave you the oppontuniy to mess up your code. In a forum you usually write BBCode (or similar), that is server-side parsed with the same hacks as the HTML5 parser, while in other context it is definitely more powerful to write directly HTML Secondly, this: pClick on my icon a href=somewhere.htmlimg width=88 height=15 src=myicon.png/p is valid HTML although not valid XHTML. Do you mean this with messing up your code? Could not save you post, invalid XML markup (Mismatched end tag, expecting img, found /p) See W3C XML1.1 specification (link to XML spec) for further information about this. Or just Not well-formed (attribute values must be encoded in double quotes) The current error messages are crap, that is totally right. They could certainly be more user-friendly. Have you got any ideas? You have no page, thus no way to edit! The admin interface should be always well-formed, having the offending portion in a textarea (or similar) for easy editing and an iframe for viewing. In any case, it is not allowable for companies to have their site down because of an user, even for just few minutes (if your lucky and find bug immediately)
Re: [whatwg] Thoughts on HTML 5
Am Dienstag, den 16.12.2008, 15:02 +0100 schrieb Giovanni Campagna: 2) XML serialization is much more difficlut to implement than old HTML, and, as i said before, in many cases it is not implementable at all: probably a company which hosts user-generated content such as blogs or forums won't like that no browser can display his pages because someone wrote invalid html It is not hard to reject input if its not well-formed. If browsers can do it, why shouldn't web apps be able to ? even the most experienced can mis-type code, and in that case the only way to solve is to manually edit source using a plain text editor, which is not possible with user-generated content As I said, invalid input should be rejected in the first place. When I write a blog post, I usually catch errors like this when I click on the preview button and its all yellow. -- Nils Dagsson Moskopp http://dieweltistgarnichtso.net
Re: [whatwg] Thoughts on HTML 5
Am Dienstag, den 16.12.2008, 14:14 +0100 schrieb Giovanni Campagna: Maybe so-called invalid HTML attributes are not the only solution, but in my opinion it is a simple way to embed metadata within any element. What metadata are you talking about ? Microformats already exist. Personally I prefer the latter (XML) solution, but there are context where using XML serialization is not possibile (for example in user generated content) so there is a definite need for a SGML way to add custom attributes without conflicting with standards. HTML5 is not derived from SGML anymore. Greetings -- Nils Dagsson Moskopp http://dieweltistgarnichtso.net
Re: [whatwg] Thoughts on HTML 5
2008/12/16 Nils Dagsson Moskopp
nils-dagsson-mosk...@dieweltistgarnichtso.net
Am Dienstag, den 16.12.2008, 14:14 +0100 schrieb Giovanni Campagna:
Maybe so-called invalid HTML attributes are not the only solution,
but in my opinion it is a simple way to embed metadata within any
element.
What metadata are you talking about ? Microformats already exist.
I'm talking of any data that is related semantically to element and should
not be printed to the user or interact with default browser behaviour. There
is an example in the HTML5 spec of an element representing a spaceship in a
browser game, with data- attributes to provide fire / armour values
Imagine the spaceship has class spaceship, then i can write the following
css:
.spaceship:after {
display:block;
height: 10px;
width: attr(data-attack,px);
background-color: red;
color: white;
text-align: center;
content: Attack value attr(data-attack,string);
}
.spaceship:after:after {
display:block;
height: 10px;
width: attr(data-defence,px);
background-color: green;
color: white;
text-align: center;
content: Defence value attr(data-defence,string);
}
(The same behaviour can be achieved also with a @namespace rule, putting
non-standard attributes in an application-specific namespace)
Personally I prefer the latter (XML) solution, but there are context
where using XML serialization is not possibile (for example in user
generated content) so there is a definite need for a SGML way to add
custom attributes without conflicting with standards.
HTML5 is not derived from SGML anymore.
My fault, I meant the HTML serialization of HTML5.
Giovanni Campagna
Re: [whatwg] Thoughts on HTML 5
Maybe so-called invalid HTML attributes are not the only solution, but in my opinion it is a simple way to embed metadata within any element. Imagine that such markup is then passed to a web application through XHR. In that case scripts aren't parsed and executed. In this case you have three ways to attach a behaviour: 2) on-event standard attributes (but they not performant since they're parsed every time the event fires and the cannot include chars like or , they need to be escaped) 3) assigning a class and some metadata using data-, then getElementsByClassName and addEventListener The same with CSS: you can use style for each element or data- attributes queried by attr() For what concerns browser support, these attributes are at all part of the DOM tree, so I can pass their names to getAttribute and setAttribute, but they don't get any special interface. It's the same in the XML serialization with different application-specific namespaces: they use only DOMAttr interface defined in DOM3Core and they're not part of any infoset (not part of ID list or NAME list) Personally I prefer the latter (XML) solution, but there are context where using XML serialization is not possibile (for example in user generated content) so there is a definite need for a SGML way to add custom attributes without conflicting with standards.
Re: [whatwg] Thoughts on HTML 5
I tried following this thread but I can't find what I would need to change in the spec to address the feedback so far. If this feedback relates to requests for the spec, please elaborate on exactly what it is that should change -- thanks! -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Thoughts on HTML 5
On Sat, Dec 13, 2008 at 1:40 AM, Garrett Smith dhtmlkitc...@gmail.com wrote: On Thu, Feb 28, 2008 at 10:31 AM, h...@nczonline.net wrote: We then, as developers, could use that attribute as we see fit and the document would still validate (for people who care about such things). Are people who care about things are the parenthetical afterthought? Just curious: What are you expecting your invalid html and custom attributes to do? Control scripts, usually. This is a valid and common use-case that currently has to hack around things, sometimes by embedding this data in the class attribute. The data-* attribute family is explicitly designed for this. ~TJ
[whatwg] Thoughts on HTML 5
On Mon, Dec 15, 2008 at 6:32 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Sat, Dec 13, 2008 at 1:40 AM, Garrett Smith dhtmlkitc...@gmail.com wrote: On Thu, Feb 28, 2008 at 10:31 AM, h...@nczonline.net wrote: We then, as developers, could use that attribute as we see fit and the document would still validate (for people who care about such things). Are people who care about things are the parenthetical afterthought? Just curious: What are you expecting your invalid html and custom attributes to do? Control scripts, usually. This is a valid and common use-case that currently has to hack around things, sometimes by embedding this data in the class attribute. The data-* attribute family is explicitly designed for this. You're not Nicholas. We don't know if that is what Nicholas expects his HTML to do or if he is expecting something else. In absence of an example, I can't do much more than guess. I cannot expect your assumptions to be correct. You've not stated how creating invalid HTML can control scripts. Having an interest in scripting, I would like to know how this works. Garrett ~TJ
Re: [whatwg] Thoughts on HTML 5
You're not Nicholas. We don't know if that is what Nicholas expects his HTML to do or if he is expecting something else. In absence of an example, I can't do much more than guess. I cannot expect your assumptions to be correct. Well, of course, but you sent the message to the entire group, so you should be ready for answers from the whole group. ^_^ You've not stated how creating invalid HTML can control scripts. Having an interest in scripting, I would like to know how this works. Dude, come on. You're trying to poison the dialogue here. The point isn't to create invalid HTML. It's to put metadata on elements, which is most easily accomplished through custom attributes. This does (currently, in HTML4) happen to be invalid, but it's hardly on the level of your standard invalid html produced by a novice author. As to how custom attributes can help control scripts, look into any decent javascript plugin. Many of them utilize some form of metadata when interacting with the DOM. This can be passed into the plugin via a function call, or embedded into a nearby script, but it's often much easier to simply embed it directly on the element that's being affected by the plugin. This way you don't have to put in any extra work to scope the metadata to the appropriate element. Sometimes you can do this by adding classes onto the element, but sometimes you can't (well, at least not without quite a bit of hackery). Just adding a new attribute can be much simpler and more appropriate. As noted, this is why Ian added the data-* attribute family. This discussion we're having has already been settled - custom attributes are a useful thing to script authors, and so HTML5 has an officially blessed version of them. ~TJ
Re: [whatwg] Thoughts on HTML 5
On Mon, Dec 15, 2008 at 8:02 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: You're not Nicholas. We don't know if that is what Nicholas expects his HTML to do or if he is expecting something else. In absence of an example, I can't do much more than guess. I cannot expect your assumptions to be correct. Well, of course, but you sent the message to the entire group, so you should be ready for answers from the whole group. ^_^ You've not stated how creating invalid HTML can control scripts. Having an interest in scripting, I would like to know how this works. Dude, come on. You're trying to poison the dialogue here. The point Instead of a complaining about my intentions, why don't you post an example that shows the problem (demonstrate need), how the problem is overcome (the invalid HTML solution), and what browsers actually do? I've seen code that has invalid attributes. These attributes won't always have the same effect as the author wanted them to. Not all authors expect the same thing from their invalid HTML. Recent c.l.js discussions have included examples of page author using a named element where that element does not support the name attribute, e.g. span name='fred'. The author had expected the element to be included with getElementsByName, but it wasn't. (not the first time someone has expected nonstandard behavior from an attribute). I've seen other uses of invalid HTML that did what the author wanted to in most cases. Valid HTML can have a clear and expected outcome. If something is done according to standard, it can be expected that that something will produce the outcome specified. If it doesn't, it would be your fault. As to how custom attributes can help control scripts, look into any decent javascript plugin. Many of them utilize some form of metadata What is a javascript plugin? The param element is designed for associating data with a plugin, such as a swf movie. Is this an allusion? Garrett ~TJ
Re: [whatwg] Thoughts on HTML 5
On Mon, Dec 15, 2008 at 6:36 PM, Garrett Smith dhtmlkitc...@gmail.com wrote: On Mon, Dec 15, 2008 at 8:02 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: Valid HTML can have a clear and expected outcome. If something is done according to standard, it can be expected that that something will produce the outcome specified. If it doesn't, it would be your fault. (for using a non standard approach.) Garrett Garrett ~TJ
Re: [whatwg] Thoughts on HTML 5
On Thu, Feb 28, 2008 at 10:31 AM, h...@nczonline.net wrote: We then, as developers, could use that attribute as we see fit and the document would still validate (for people who care about such things). - Are people who care about things are the parenthetical afterthought? Just curious: What are you expecting your invalid html and custom attributes to do? Garrett -Nicholas
Re: [whatwg] Thoughts on HTML 5
(Not all of this e-mail is covered in this reply. It's possible that I will reply to the same points in this e-mail multiple times, for which I apologise in advance.) On Thu, 28 Feb 2008 [EMAIL PROTECTED] wrote: * I'm not sure what the section/ element offers over the div/ element. I thought the purpose of the div/ was to indicate a section of the page. If there's not a clear distinction between these elements, I don't see the need for a second one. Please see: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-July/015506.html ...for a discussion on this matter. * I'm a bit unsure of the article/ element. As with section/, it seems only vaguely different from div/ and too focused on solving the question of what markup to use for a blog. Blogs and forums and news articles, yes. Those are quite a big use case on the Web. :-) * The aside/ element really pushes the boundaries of marking up literary devices. I'm not sure enough web developers know what an aside actually is. Short asides are typically indicated by parentheses and I don't see any reason not to keep doing that (seriously). Any element that requires someone to ask an English teacher when it should be used is probably a bad idea. There are a lot of asides on the Web. Ads, side notes, indeed almost anything in a sidebar other than navigation, etc. * The dfn/ is another that stresses the understanding of grammatical structure for web developers. The intent is to designate the defining instance of a term, abberviation, or acronym. Does that make sense to you? If it did, give yourself one point; if it didn't, don't feel bad, most people won't get it. Again, any element that leaves people scratching their heads probably isn't necessary or useful. It's an element that I use a lot in HTML5 itself. I agree that it's not a big target audience, as it were, but since it's already implemented it's a lot easier for us to add it than it would be to add other elements with little potential usage. * Speaking of confusing, I've read the section about the meter/ element five times now and still have no idea what it's used for. Do the examples not help? * I'd like to see some treatment of rich text input controls. Right now we all use a hack (an iframe in design mode) that has to be copied over into a form field to be submitted. It would be nice to have this handled natively and have reliable HTML formatting of that content (instead of the per-browser implementations we have now). Sadly the problem is that while everyone agrees on the need, nobody agrees on exactly what the profile of HTML that should be allowed is, and short of including an entire schema language, there doesn't seem to be a good solution. The spec now gets around this by just providing a generic mechanism and relying on the scripts to implement whatever restrictions they want. * I'd like to see a common attribute that can be used on any element to indicate information related to the element. I'm tired of fighting the custom attribute battle. The fact is that it's a very common need to include extra data related to an element. I'd propose a reldata attribute (short for related data) be considered as an optional attribute on all elements. We then, as developers, could use that attribute as we see fit and the document would still validate (for people who care about such things). We've added data-* for this. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Thoughts on HTML 5
On Sat, 1 Mar 2008, Nicholas C. Zakas wrote: As there is also another thread going on about section/, I don't want to repeat all of my comments here, but suffice to say that I don't see why I'd ever use section/ when I get implicit sections by using hn/ elements. Writers are used to headings indicating sections, and don't really think of a section as anything on its own. I can understand the use of article/ as semantically indicating that the area contains information rather than markup, but I think section/ is overkill. I think it won't be used by everyone, but some people have indicated a clear desire to not have to worry about the numbering of headers. I understand your reasoning for the aside/ element, perhaps this is another element that is suffering from the wrong name. Most of web developers have no idea what an aside is let alone when to use one. I know that acronym/ was removed because it confused web developers. Given that this is the same audience, the ones who couldn't figure out the difference between an acronym and an abbreviation, do you really think that aside/ will get used? Perhaps it would better be named callout/? sidebar might be ok, but I wanted to avoid being too specific about the presentation in the name. (acronym was removed because it's redundant with abbr.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Thoughts on HTML 5
On Sat, 8 Mar 2008, Nicholas C. Zakas wrote: From: Shannon [EMAIL PROTECTED] Dnia 01-03-2008, So o godzinie 19:36 -0800, Nicholas C. Zakas pisze: Perhaps it would better be named callout/? Aside is customary in dialogue annotations, I have never seen any callout. Call it note. It may sound crude but it's hard to mistake its meaning. Oooh, I like that better. @Chris - I understand what an aside is, I just know for a fact that most people do not. Shannon's suggestion of note makes much more sense to me than my suggestion of callout. Long live note/! note and callout aren't really generic enough. e.g. in HTML5 aside would be used for both the notes and the examples in the spec, but note would only sound like it was ok for the notes. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Thoughts on HTML 5
Ian Hickson wrote: On Sat, 8 Mar 2008, Nicholas C. Zakas wrote: From: Shannon [EMAIL PROTECTED] Dnia 01-03-2008, So o godzinie 19:36 -0800, Nicholas C. Zakas pisze: Perhaps it would better be named callout/? Aside is customary in dialogue annotations, I have never seen any callout. Call it note. It may sound crude but it's hard to mistake its meaning. Oooh, I like that better. @Chris - I understand what an aside is, I just know for a fact that most people do not. Shannon's suggestion of note makes much more sense to me than my suggestion of callout. Long live note/! note and callout aren't really generic enough. e.g. in HTML5 aside would be used for both the notes and the examples in the spec, but note would only sound like it was ok for the notes. I think web developers would prefer pointless, distraction, wasteofspace or bossmademedoit. Shannon
Re: [whatwg] Thoughts on HTML 5 - dialog
Ernest Cline wrote: The only synonym of dialog that is anywhere near as general seems to be discourse/. And I accidentally replied off list: Discourse is too general. In philosophy and theology a discourse can mean teaching, as in Levinas' discourse about 'the other' has made alterity a recurring theme in all modern philosophy or pentecostal theology is defined by its discourse about the charims. I would not associate discourse with a spoken list-like dialog. That would be way too narrow. Lars Gunther
Re: [whatwg] Thoughts on HTML 5 - dialog
Tab Atkins Jr. wrote: My personal favorite alternate suggestion so far has been cl. Yes, I also quite like the analogy with dl/ul/ol. But it may be confusing when using dt and dd as child elements (as in the current spec for dialog): cl dt dd ... /cl That could be resolved by introducing elements ct and cd: cl ct cd ... /cl and that I guess can be regarded as making things better OR worse depending on your focus... Best regards Mike Wilson
Re: [whatwg] Thoughts on HTML 5 - dialog
-Original Message- From: Mike Wilson [EMAIL PROTECTED] Sent: May 15, 2008 8:02 AM To: 'WHATWG' [EMAIL PROTECTED] Subject: Re: [whatwg] Thoughts on HTML 5 - dialog Yes, I also quite like the analogy with dl/ul/ol. But it may be confusing when using dt and dd as child elements (as in the current spec for dialog): cl dt dd ... /cl That could be resolved by introducing elements ct and cd: cl ct cd ... /cl and that I guess can be regarded as making things better OR worse depending on your focus... Best regards Mike Wilson Because of the backwards compatibility using dt and dd with a new dialog element would have with most existing UA's, I'd be leery of changing the names unless additional types of child elements for dialog/ (by whatever name it gets) were added, such as an element to markup stage directions, audience response, or the like. Then, since we'd be introducing enough new stuff to break compatibility anyway: dialog/ speaker/ (what dt/ currently is) speech/ (what dd/ currently is) fx/ (a new element for stage effects, audience response etc.)
Re: [whatwg] Thoughts on HTML 5 - dialog
On Thu, May 15, 2008 at 6:20 PM, Ernest Cline [EMAIL PROTECTED] wrote: -Original Message- From: Mike Wilson [EMAIL PROTECTED] Sent: May 15, 2008 8:02 AM To: 'WHATWG' [EMAIL PROTECTED] Subject: Re: [whatwg] Thoughts on HTML 5 - dialog Yes, I also quite like the analogy with dl/ul/ol. But it may be confusing when using dt and dd as child elements (as in the current spec for dialog): cl dt dd ... /cl That could be resolved by introducing elements ct and cd: cl ct cd ... /cl and that I guess can be regarded as making things better OR worse depending on your focus... Best regards Mike Wilson Because of the backwards compatibility using dt and dd with a new dialog element would have with most existing UA's, I'd be leery of changing the names unless additional types of child elements for dialog/ (by whatever name it gets) were added, such as an element to markup stage directions, audience response, or the like. Then, since we'd be introducing enough new stuff to break compatibility anyway: dialog/ speaker/ (what dt/ currently is) speech/ (what dd/ currently is) fx/ (a new element for stage effects, audience response etc.) Yeah, I'm backing off of that position... I'm back to liking plain dialog or talk. Either sounds great to me. ~TJ
Re: [whatwg] Thoughts on HTML 5 - dialog
Zachary Carter wrote: FWIW, in my first encounter with HTML5 dialog I assumed it meant a dialog box. Yes, I assumed the same thing. I think it would be better to not use such an overloaded term for the stated purpose. The spec itself uses dialog in both meanings: 3.4.6 ... tabbed dialogs ... (= dialog box) 3.9.5 dialog element (= conversations) 4.2 ... showModalDialog (= dialog box) 4.5.1 Simple dialogs (= dialog boxes) I think it would be better to choose any other word from the suggested ones, as I think most of them do not already have another meaning within the HTML5 spec. The first paragraph of 3.9.5 gives a hint: The dialog element represents a conversation. so my first recommendation would be to go for conversation and live with its length. Many other element names are abbreviated so could also opt for that: convers spkdlg (spoken dialog) etc etc. Ian Hickson wrote: I agree that the initial name, if that's all you see, has the opportunity to confuse, but once you read what the element was really for, did the confusion continue to be a problem? Personally, I guess I can learn the intended meaning of the element. But, each time I see the element there is a feeling that this is wrong and I have to focus to remember the element's real purpose. I guess this is what more people are feeling and that this is why you are getting so much feedback on this fairly simple issue. Best regards Mike Wilson
Re: [whatwg] Thoughts on HTML 5 - dialog
On Wed, 14 May 2008, Mike Wilson wrote: Yes, I assumed the same thing. I think it would be better to not use such an overloaded term for the stated purpose. I agree in principle, but the alternatives, e.g.: so my first recommendation would be to go for conversation and live with its length. Many other element names are abbreviated so could also opt for that: convers spkdlg (spoken dialog) ...are all worse (far too long in the case of the first suggestion above, and inconsistent with the style of the rest of the language for the other two). Some words have multiple meanings, and when we introduce elements that use those words it can initially be confusing, but I'm sure than ten years from now people will by and large not have a problem with it, just like by and large people don't have a problem with script or map these days. And, to put this in perspective, we have far worse names in the language already, like address. Not that that is a good defence. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Thoughts on HTML 5 - dialog
Ian Hickson wrote: On Tue, 13 May 2008, Ernest Cline wrote: I agree that dialog isn't perfect and could be (and has been) confused with dialog boxes, but I'm not convinced it's not the best name for the job anyway. The other possibility is dialogue/ since the computing uses that cause confusion seem to have standardized on the shorter spelling. Experience with language= on script suggests that many authors have serious difficulties spelling words that contain the gu letter pair. I, too, think that the word dialog sounds more like dialog window or dialog box than a dialogue. I'd prefer dialogue over dialog for following reasons: - cannot be confused with dialog box or dialog window - the dialogue tag would probably most often be generated by CMS system or authoring software so spelling errors are not such a big issue - dialogue is pretty seldom used feature and I believe it doesn't deserve any shorter tag If dialog is used instead of dialogue then it should be designed in a such way that it can be used for dialog box in addition to dialogue (e.g. chat) in the future. -- Mikko signature.asc Description: OpenPGP digital signature
Re: [whatwg] Thoughts on HTML 5
Karl Dubost writes: Le 14 mai 2008 à 07:09, Ian Hickson a écrit : That [talk is] probably the best suggestion so far, but I'm still not convinced it's really much better than dialog . I think it has at least as many other interpretations (e.g. what we call a talk over here is really a slide show). Indeed; as a noun a talk seems to refer to a presentation more often than the action of talking. talking would be less subject to misinterpretation, but the gerund form makes an awkward tag name. food for thoughts * conversation (probably too long) It's more specific than 'dialogue', which might incorrectly suggest it isn't appropriate to use it for dialogue that isn't a conversation. * colloquy Ditto, but also it's a less-well-known word and harder to spell! * chat (probably too IRC, messenger oriented, though here I suspect my own distortion field. People often says let's have a chat.) People do say that. But this element would also be the one used for marking up Shakespeare's plays, and labelling them as chats seems a touch barbaric. * dialogue (was wondering if it was less geeky than dialog, not sure) I think so, but that's because probably I'm from the UK where dialog is a spelling mistake in general use, so only occurs in narrow technical contexts. Elsewhere HTML takes USA spellings (color, etc), so it would be bad to pick dialogue if most USA speakers would naturally spell it dialog. (Though having either of them is likely to lead _some_ group to accidentally using t'other spelling.) * discourse Too obscure/specific. * speech I quite like that. It could be misinterpreted as a speech rather than some speech, but it may be the least-bad. * converse More commonly it's a verb than a noun, which makes it awkward. Smylers
Re: [whatwg] Thoughts on HTML 5 - dialog
On Wed, May 14, 2008 at 3:36 AM, Mikko Rantalainen [EMAIL PROTECTED] wrote: If dialog is used instead of dialogue then it should be designed in a such way that it can be used for dialog box in addition to dialogue (e.g. chat) in the future. I severely doubt this is possible or desirable. It would make it *more* confusing, I think, if dialog was meant for dialog boxes *and* marking up conversations. Just to throw out yet another possibility, how about convo? I don't like it too much, but it at least avoids most of the issues that plagued the other submissions. I'm generally convinced that dialog is an okay choice for this, but if we *were* to change, I at least want to make sure it's something I can get behind. My personal favorite alternate suggestion so far has been cl. Short and a little confusing? Maybe. But it has the benefit of being unambiguous and parallels existing tags with similar syntax. But meh, it's probably not quite right, as dialog isn't meant to be illustrating a conversation list, but rather is a list illustrating a conversation. ~TJ
Re: [whatwg] Thoughts on HTML 5
2008/5/13 Ian Hickson [EMAIL PROTECTED]: On Tue, 13 May 2008, Paweł Stradomski wrote: [...] Perhaps talk ? Short and simple, although not exactly equal in meaning to dialog. That's probably the best suggestion so far, but I'm still not convinced it's really much better than dialog. I think it has at least as many other interpretations (e.g. what we call a talk over here is really a slide show). Honestly, though, are we concerned that people will think a talk element in html refers to a slideshow? The ambiguity of dialog occurs because there is a very reasonable and natural interpretation for the element name within the context of web applications that happens to be completely wrong. talk, while certainly ambiguous in some ways, is extremely clear within the context of a web application. There is no other major existing entity or idea with the same or similar name for it to clash with. Plus, it's easy to spell, easy to remember, neither pretentious nor overly casual (useful both for IRC and Shakespeare!), and hits the intended meaning of the element (modulo the slight ambiguity) very well. From what I can tell, that's the entire checklist of objections that have been raised over previous name suggestions. talk seems to pass with flying colors. ~TJ
Re: [whatwg] Thoughts on HTML 5
converse is more an adjective like opposite to me. Which is even more awkward. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Smylers Sent: Wednesday, May 14, 2008 2:12 PM To: whatwg@lists.whatwg.org Subject: Re: [whatwg] Thoughts on HTML 5 Karl Dubost writes: * converse More commonly it's a verb than a noun, which makes it awkward. Smylers
Re: [whatwg] Thoughts on HTML 5
Commands typed at a computer prompt do form a conversation between the commander and the executor (if the executor responds - otherwise it is good old CODE). On the other hand, a speech is closer to a monologue (soliloquy). Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Smylers Sent: Wednesday, May 14, 2008 2:16 PM To: whatwg@lists.whatwg.org Subject: Re: [whatwg] Thoughts on HTML 5 Krzysztof Żelechowski writes: I recommend transcript because it refers to a conversation that has been put down However many things in webpages are things which have been written down! This is specifically a transcript of some speech -- not a transcript of commands typed at a computer prompt, nor an exam transcript, nor any other kind of transcript. So focusing on the thing being transcribed, the speech, seems more sensible; that it has been written down is something which will be readily apparent to anybody reading it! Smylers
Re: [whatwg] Thoughts on HTML 5 - dialog
Ian Hickson wrote: On Tue, 13 May 2008, Zachary Carter wrote: FWIW, in my first encounter with HTML5 dialog I assumed it meant a dialog box. This might be due to my experience with the dialog element in XUL[1], which is used for that. Also, dialog boxes are generally more common from my browsing experience, so I hadn't considered the alternative usage at first. I agree that the initial name, if that's all you see, has the opportunity to confuse, but once you read what the element was really for, did the confusion continue to be a problem? Of course most people using these elements won't be reading the spec. It is quite likely that someone will assume dialog is the correct tag to use for a CSS+JS dialog box. ~fantasai
Re: [whatwg] Thoughts on HTML 5 - dialog
On Wed, May 14, 2008 at 11:37 AM, fantasai [EMAIL PROTECTED] wrote: Ian Hickson wrote: On Tue, 13 May 2008, Zachary Carter wrote: FWIW, in my first encounter with HTML5 dialog I assumed it meant a dialog box. This might be due to my experience with the dialog element in XUL[1], which is used for that. Also, dialog boxes are generally more common from my browsing experience, so I hadn't considered the alternative usage at first. I agree that the initial name, if that's all you see, has the opportunity to confuse, but once you read what the element was really for, did the confusion continue to be a problem? Of course most people using these elements won't be reading the spec. It is quite likely that someone will assume dialog is the correct tag to use for a CSS+JS dialog box. They are reasonably unlikely to ship a web page that assumes that, though. People who don't read specs generally build web pages by copying and pasting from other web pages. They don't just think up random things they'd like to see and try them out to see if they work. So people looking for a dialog box are going to be looking for an example with a dialog box, which will _not_ reference the dialog element, so they won't be particularly confused. People looking for an example of how to express back-and-forth dialogue will find a web page which does so, which does use the dialog element, and they will also not be confused. Or at least they won't be materially more or less confused than they would be if the tag was al or something (al for alternating list). -scott
Re: [whatwg] Thoughts on HTML 5 - dialog
My personal favorite alternate suggestion so far has been cl. throat-warbler-mangrove, anyone? Of course it's not pronounced that way. - Charles
Re: [whatwg] Thoughts on HTML 5
On Thu, 28 Feb 2008 [EMAIL PROTECTED] wrote: I've just finished taking a look at the working draft of HTML 5 and thought I'd share my thoughts. Clearly, HTML 5 is meant as an evolution of HTML 4, which has both its good and bad points. Accordingly, there are both good and bad parts of the specification. My thoughts are as follows: (I've omitted replies to some parts of your e-mail. I have saved your e-mail for further replies to those sections later.) * I understand the concept of the dialog/ element but it's named completely wrong. The point is to markup a conversation between two or more parties. The problem is that the word dialog, when in used in user interfaces, refers to small windows that can be interacted with. When I first read about this element, I assumed it was a way to indicate that part of the page is a dialog window outside of the normal flow of the document (which I thought was cool). After reading the rest, I was disappointed to find out that wasn't the intent. I'd rename this element as conversation/ or discussion/ to avoid such misunderstandings. I agree that the name is suboptimal but those names are worse (they're too long, and they're overly specific). I'm not sure what to do about this. * The dfn/ is another that stresses the understanding of grammatical structure for web developers. The intent is to designate the defining instance of a term, abberviation, or acronym. Does that make sense to you? If it did, give yourself one point; if it didn't, don't feel bad, most people won't get it. Again, any element that leaves people scratching their heads probably isn't necessary or useful. dfn doesn't have to be used, but for certain cases it's very useful. I don't think it's a problem to keep it. * Speaking of confusing, I've read the section about the meter/ element five times now and still have no idea what it's used for. I don't know how to improve the current text. Does the example showing the newsgroups activity help at all? The real reason for meter is that we need to make sure people don't abuse progress just to show gauges (e.g. disk space usage). Does that make sense? How should we go about better describing this? * I'd like to see some treatment of rich text input controls. Right now we all use a hack (an iframe in design mode) that has to be copied over into a form field to be submitted. It would be nice to have this handled natively and have reliable HTML formatting of that content (instead of the per-browser implementations we have now). Also contenteditable doesn't solve my issue with rich text editing. It solves the ability to do it, but not a straightforward way to do it in the context of a form and submit it back to the server without some intermediary code. My point is that there should be a way to submit rich text in a form by default, without needing to write extra JavaScript code. The problem is that while everyone seems to want a rich text control, nobody seems to agree on exactly what it should allow. Thus contenteditable, and the ability for people to roll their own. * I'd like to see a common attribute that can be used on any element to indicate information related to the element. I'm tired of fighting the custom attribute battle. The fact is that it's a very common need to include extra data related to an element. I'd propose a reldata attribute (short for related data) be considered as an optional attribute on all elements. We then, as developers, could use that attribute as we see fit and the document would still validate (for people who care about such things). We recently added data-*=, does that help? http://www.whatwg.org/specs/web-apps/current-work/#data- Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Thoughts on HTML 5
W liście Ian Hickson z dnia wtorek 13 maja 2008: * I understand the concept of the dialog/ element but it's named completely wrong. The point is to markup a conversation between two or more parties. The problem is that the word dialog, when in used in user interfaces, refers to small windows that can be interacted with. When I first read about this element, I assumed it was a way to indicate that part of the page is a dialog window outside of the normal flow of the document (which I thought was cool). After reading the rest, I was disappointed to find out that wasn't the intent. I'd rename this element as conversation/ or discussion/ to avoid such misunderstandings. I agree that the name is suboptimal but those names are worse (they're too long, and they're overly specific). I'm not sure what to do about this. Perhaps talk ? Short and simple, although not exactly equal in meaning to dialog. -- Paweł Stradomski
Re: [whatwg] Thoughts on HTML 5 - dialog
-Original Message- From: Ian Hickson [EMAIL PROTECTED] Sent: May 13, 2008 6:09 PM To: Paweł Stradomski [EMAIL PROTECTED] Cc: whatwg@lists.whatwg.org Subject: Re: [whatwg] Thoughts on HTML 5 On Tue, 13 May 2008, Paweł Stradomski wrote: W liście Ian Hickson z dnia wtorek 13 maja 2008: * I understand the concept of the dialog/ element but it's named completely wrong. The point is to markup a conversation between two or more parties. The problem is that the word dialog, when in used in user interfaces, refers to small windows that can be interacted with. When I first read about this element, I assumed it was a way to indicate that part of the page is a dialog window outside of the normal flow of the document (which I thought was cool). After reading the rest, I was disappointed to find out that wasn't the intent. I'd rename this element as conversation/ or discussion/ to avoid such misunderstandings. I agree that the name is suboptimal but those names are worse (they're too long, and they're overly specific). I'm not sure what to do about this. Perhaps talk ? Short and simple, although not exactly equal in meaning to dialog. That's probably the best suggestion so far, but I'm still not convinced it's really much better than dialog. I think it has at least as many other interpretations (e.g. what we call a talk over here is really a slide show). The only synonym of dialog that is anywhere near as general seems to be discourse/. The other possibility is dialogue/ since the computing uses that cause confusion seem to have standardized on the shorter spelling.
Re: [whatwg] Thoughts on HTML 5 - dialog
On Tue, 13 May 2008, Ernest Cline wrote: The only synonym of dialog that is anywhere near as general seems to be discourse/. I dunno, that just sounds so formal. I agree that dialog isn't perfect and could be (and has been) confused with dialog boxes, but I'm not convinced it's not the best name for the job anyway. The other possibility is dialogue/ since the computing uses that cause confusion seem to have standardized on the shorter spelling. Experience with language= on script suggests that many authors have serious difficulties spelling words that contain the gu letter pair. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Thoughts on HTML 5 - dialog
On Tue, 13 May 2008, Ernest Cline wrote: I agree that the word discourse is more formal than dialog, but it does cover both formal and informal speech unlike some other thesaurus inspired possibilities such as colloquy or chat. Sure, I'm just reluctanct to use an element name that is too formal, as (for better or worse) that makes the language sound stilted. It does have the advantage over dialog of avoiding the spelling issue and the computer term issue. If those issues end up being judged sufficient to make dialog/ undesirable, then discourse/ seems to me to be the best alternative available among English words. Of course, if words were abandoned altogether d/ would also be a possibility. d is probably too short for an element that won't be used that much. Unless we get more evidence that the confusion with dialog boxes is a real blocker to adoption, I'm going to assume that dialog is our best option. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Thoughts on HTML 5 - dialog
-Original Message- From: Ian Hickson [EMAIL PROTECTED] Sent: May 13, 2008 8:08 PM Unless we get more evidence that the confusion with dialog boxes is a real blocker to adoption, I'm going to assume that dialog is our best option. Is there any reasonable chance an element for a dialog box might end up being added to XForms? (There is a proposal mentioned on the XForms wiki [1] for a possible dialog element for XForms 2.0, but I have no idea how much of a chance that proposal has as opposed to extending the message element.) I know that XHTML 5 + XForms isn't a major concern, but I do think that avoiding a problem for those that will be using various flavors of XHTML with XForms is worth addressing now. If XForms were to add an explicit dialog box element, what name other than dialog/ would be appropriate? [1] http://www.w3.org/MarkUp/Forms/wiki/Dialogs
Re: [whatwg] Thoughts on HTML 5
Le 14 mai 2008 à 07:09, Ian Hickson a écrit : That's probably the best suggestion so far, but I'm still not convinced it's really much better than dialog. I think it has at least as many other interpretations (e.g. what we call a talk over here is really a slide show). food for thoughts * colloquy * conversation (probably too long) * chat (probably too IRC, messenger oriented, though here I suspect my own distortion field. People often says let's have a chat.) * dialogue (was wondering if it was less geeky than dialog, not sure) * discourse * speech * talking * converse -- Karl Dubost - W3C http://www.w3.org/QA/ Be Strict To Be Cool
Re: [whatwg] Thoughts on HTML 5 - dialog
FWIW, in my first encounter with HTML5 dialog I assumed it meant a dialog box. This might be due to my experience with the dialog element in XUL[1], which is used for that. Also, dialog boxes are generally more common from my browsing experience, so I hadn't considered the alternative usage at first. [1]http://developer.mozilla.org/en/docs/XUL:dialog On Tue, May 13, 2008 at 8:08 PM, Ian Hickson [EMAIL PROTECTED] wrote: On Tue, 13 May 2008, Ernest Cline wrote: I agree that the word discourse is more formal than dialog, but it does cover both formal and informal speech unlike some other thesaurus inspired possibilities such as colloquy or chat. Sure, I'm just reluctanct to use an element name that is too formal, as (for better or worse) that makes the language sound stilted. It does have the advantage over dialog of avoiding the spelling issue and the computer term issue. If those issues end up being judged sufficient to make dialog/ undesirable, then discourse/ seems to me to be the best alternative available among English words. Of course, if words were abandoned altogether d/ would also be a possibility. d is probably too short for an element that won't be used that much. Unless we get more evidence that the confusion with dialog boxes is a real blocker to adoption, I'm going to assume that dialog is our best option. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' -- Zach Carter
Re: [whatwg] Thoughts on HTML 5 - dialog
On Tue, 13 May 2008, Ernest Cline wrote: Unless we get more evidence that the confusion with dialog boxes is a real blocker to adoption, I'm going to assume that dialog is our best option. Is there any reasonable chance an element for a dialog box might end up being added to XForms? (There is a proposal mentioned on the XForms wiki [1] for a possible dialog element for XForms 2.0, but I have no idea how much of a chance that proposal has as opposed to extending the message element.) I know that XHTML 5 + XForms isn't a major concern, but I do think that avoiding a problem for those that will be using various flavors of XHTML with XForms is worth addressing now. If XForms were to add an explicit dialog box element, what name other than dialog/ would be appropriate? There are a number of other much more important conflicts between XForms and HTML at this point, I don't think this is a particularly big concern. On Wed, 14 May 2008, Karl Dubost wrote: food for thoughts * conversation (probably too long) * chat (probably too IRC, messenger oriented, though here I suspect my own distortion field. People often says let's have a chat.) * dialogue (was wondering if it was less geeky than dialog, not sure) * discourse These have been suggested in recent threads. * colloquy I would imagine this would confuse more people than dialog. * speech This has the same problem as talk, which was also suggested recently. * talking * converse These are not in the same style (nouns) as other tags, which would lead to a language consistency problem. On Tue, 13 May 2008, Zachary Carter wrote: FWIW, in my first encounter with HTML5 dialog I assumed it meant a dialog box. This might be due to my experience with the dialog element in XUL[1], which is used for that. Also, dialog boxes are generally more common from my browsing experience, so I hadn't considered the alternative usage at first. I agree that the initial name, if that's all you see, has the opportunity to confuse, but once you read what the element was really for, did the confusion continue to be a problem? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Thoughts on HTML 5
Oooh, I like that better. @Chris - I understand what an aside is, I just know for a fact that most people do not. Shannon's suggestion of note makes much more sense to me than my suggestion of callout. Long live note/! -Nicholas - Original Message From: Shannon [EMAIL PROTECTED] To: whatwg@lists.whatwg.org Sent: Monday, March 3, 2008 3:40:15 PM Subject: Re: [whatwg] Thoughts on HTML 5 Dnia 01-03-2008, So o godzinie 19:36 -0800, Nicholas C. Zakas pisze: Perhaps it would better be named callout/? Aside is customary in dialogue annotations, I have never seen any callout. Chris Call it note. It may sound crude but it's hard to mistake its meaning. Shannon Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
Re: [whatwg] Thoughts on HTML 5
Dnia 01-03-2008, So o godzinie 19:36 -0800, Nicholas C. Zakas pisze: I understand your reasoning for the aside/ element, perhaps this is another element that is suffering from the wrong name. Most of web developers have no idea what an aside is let alone when to use one. I know that acronym/ was removed because it confused web developers. Given that this is the same audience, the ones who couldn't figure out the difference between an acronym and an abbreviation, do you really think that aside/ will get used? Perhaps it would better be named callout/? Aside is customary in dialogue annotations, I have never seen any callout. Chris
Re: [whatwg] Thoughts on HTML 5
Dnia 01-03-2008, So o godzinie 19:36 -0800, Nicholas C. Zakas pisze: Perhaps it would better be named callout/? Aside is customary in dialogue annotations, I have never seen any callout. Chris Call it note. It may sound crude but it's hard to mistake its meaning. Shannon
Re: [whatwg] Thoughts on HTML 5
[EMAIL PROTECTED] writes:
I had posted this on my personal blog:
http://nczonline.net/blog/2008/2/28/thoughts_on_html_5. Ian requested
I join the mailing list to continue the discussion, so here it is:
Hi there Nicholas. Welcome to the list, and thanks for your comments.
I'll try to explain the purpose of elements that you are questioning.
Where I've snipped a point you made that's generally because I
agree with you and have nothing further to add.
* the irrelevant attribute ... I can't imagine ever using it.
That's OK -- it isn't necessary for every author to use every element!
It's purpose is for use on interactive pages, where some things only
appear (or disappear), using JavaScript, after the user has done
something.
Lachlan had commented that irrelevant could be changed dynamically
to indicate parts of an application that may be relevant only during
particular points in time.
For example think of an error message which appears if the user tries to
submit invalid input: when the page initially loads the error message
isn't relevant (no error has yet occurred), but it's in the document so
that it's there if needed. At that point the script that's detected the
error condition can set irrelevant to false on the error message.
I don't see how this is any different from hiding content that isn't
necessary.
It _isn't_ different from that; it's exactly that! It's providing a
mechanism for doing precisely that -- in HTML 4 there isn't a way of
marking up an element as being hidden.
The spec says, When specified on an element, it indicates that the
element is not yet, or is no longer, relevant. User agents should
not render elements that have the irrelevant attribute specified.
If it's not relevant, why is it in the page in the first place?
So that it can become relevant in response to events.
* I'm not sure what the section/ element offers over the div/
element. I thought the purpose of the div/ was to indicate a
section of the page. If there's not a clear distinction between
these elements, I don't see the need for a second one.
div is semantically neutral; it just means that there's a division
(the author needed a block element) but doesn't give a reason for it --
similarly to how span merely denotes a run of text without giving a
reason.
In HTML 4 it's rare to need to resort to span, because there are many
other elements for denoting a span of text for a particular purpose
(em, cite, dfn, etc).
Along similar lines HTML 5 provides a block elements for specific
purposes, so that different sorts of blocks can be marked up
differently. section is one of those.
A section is not merely any block division that the author needed to
make on the page (probably to hang some styles off), but is specifically
a section (or subsection) of a document.
For example consider a webpage with this design:
* a header with the site's name and logo and so on
* a left column with navigation links
* the main page content (what the reader has come here to read) in the
middle; this is quite long, and has subheadings at various points
* a right column ('sidebar') with related information
In HTML 4 that would likely be marked up with lots of divs (or a
table). HTML 5 has meaningful elements for each of those -- header,
nav, article, and aside.
Further, article can be split into sections. Possibly the sidebar
would have sections too. Note that because of how HTML 5 infers
sections from headings it isn't necessary to include section tags to
get a section; just using h1, h2, h3, etc at the appropriate level
will achieve the same effect. But sometimes explicitly marking sections
is easier.
For an example of a document which clearly has lots of sections and
subsections see the HTML 5 spec itself!
* I'm a bit unsure of the article/ element. As with section/, it
seems only vaguely different from div/
Many HTML 5 pages will have just one article (whereas in the HTML 4
equivalent it would be necessary for that block to be just one of
several divs on the page). That will enable user-agents to know the
'main purpose' of a page. In particular text-based and speaking
browsers can offer to jump straight to it (something which authors have
to code by hand on each page in HTML 4).
* The aside/ element really pushes the boundaries of marking up
literary devices. ... Short asides are typically indicated by
parentheses and I don't see any reason not to keep doing that
(seriously).
Indeed, parens would still be the best thing to do there. If no mark-up
is needed then don't bother with any. But think of sidebars: books
often have 'boxes' out of the main flow of text describing a separate
point. These sorts of asides obviously need some mark-up, and aside
would be appropriate to use there.
* The dfn/ is another that stresses the understanding of grammatical
structure for web developers. The intent is to designate the defining
instance of a term, abberviation, or
Re: [whatwg] Thoughts on HTML 5
Thanks, I'm happy to be here. :)
Thanks for a clear explanation of the irrelevant attribute. If you see the
other thread about this, I think we've all now agreed that the purpose for the
attribute makes sense, but the name is another story. It's difficult to spell
for most people and really gives the wrong impression of the content. The
suggestion was made to rename it ignore, which I think makes more sense.
As there is also another thread going on about section/, I don't want to
repeat all of my comments here, but suffice to say that I don't see why I'd
ever use section/ when I get implicit sections by using hn/ elements.
Writers are used to headings indicating sections, and don't really think of a
section as anything on its own. I can understand the use of article/ as
semantically indicating that the area contains information rather than markup,
but I think section/ is overkill.
I understand your reasoning for the aside/ element, perhaps this is another
element that is suffering from the wrong name. Most of web developers have no
idea what an aside is let alone when to use one. I know that acronym/ was
removed because it confused web developers. Given that this is the same
audience, the ones who couldn't figure out the difference between an acronym
and an abbreviation, do you really think that aside/ will get used? Perhaps
it would better be named callout/?
-Nicholas
- Original Message
From: Smylers [EMAIL PROTECTED]
To: whatwg@lists.whatwg.org
Sent: Friday, February 29, 2008 12:02:24 AM
Subject: Re: [whatwg] Thoughts on HTML 5
[EMAIL PROTECTED] writes:
I had posted this on my personal blog:
http://nczonline.net/blog/2008/2/28/thoughts_on_html_5. Ian requested
I join the mailing list to continue the discussion, so here it is:
Hi there Nicholas. Welcome to the list, and thanks for your comments.
I'll try to explain the purpose of elements that you are questioning.
Where I've snipped a point you made that's generally because I
agree with you and have nothing further to add.
* the irrelevant attribute ... I can't imagine ever using it.
That's OK -- it isn't necessary for every author to use every element!
It's purpose is for use on interactive pages, where some things only
appear (or disappear), using JavaScript, after the user has done
something.
Lachlan had commented that irrelevant could be changed dynamically
to indicate parts of an application that may be relevant only during
particular points in time.
For example think of an error message which appears if the user tries to
submit invalid input: when the page initially loads the error message
isn't relevant (no error has yet occurred), but it's in the document so
that it's there if needed. At that point the script that's detected the
error condition can set irrelevant to false on the error message.
I don't see how this is any different from hiding content that isn't
necessary.
It _isn't_ different from that; it's exactly that! It's providing a
mechanism for doing precisely that -- in HTML 4 there isn't a way of
marking up an element as being hidden.
The spec says, When specified on an element, it indicates that the
element is not yet, or is no longer, relevant. User agents should
not render elements that have the irrelevant attribute specified.
If it's not relevant, why is it in the page in the first place?
So that it can become relevant in response to events.
* I'm not sure what the section/ element offers over the div/
element. I thought the purpose of the div/ was to indicate a
section of the page. If there's not a clear distinction between
these elements, I don't see the need for a second one.
div is semantically neutral; it just means that there's a division
(the author needed a block element) but doesn't give a reason for it --
similarly to how span merely denotes a run of text without giving a
reason.
In HTML 4 it's rare to need to resort to span, because there are many
other elements for denoting a span of text for a particular purpose
(em, cite, dfn, etc).
Along similar lines HTML 5 provides a block elements for specific
purposes, so that different sorts of blocks can be marked up
differently. section is one of those.
A section is not merely any block division that the author needed to
make on the page (probably to hang some styles off), but is specifically
a section (or subsection) of a document.
For example consider a webpage with this design:
* a header with the site's name and logo and so on
* a left column with navigation links
* the main page content (what the reader has come here to read) in the
middle; this is quite long, and has subheadings at various points
* a right column ('sidebar') with related information
In HTML 4 that would likely be marked up with lots of divs (or a
table). HTML 5 has meaningful elements for each of those -- header,
nav, article, and aside.
Further, article can be split into sections. Possibly the sidebar
would have
[whatwg] Thoughts on HTML 5
I had posted this on my personal blog: http://nczonline.net/blog/2008/2/28/thoughts_on_html_5. Ian requested I join the mailing list to continue the discussion, so here it is: I've just finished taking a look at the working draft of HTML 5 and thought I'd share my thoughts. Clearly, HTML 5 is meant as an evolution of HTML 4, which has both its good and bad points. Accordingly, there are both good and bad parts of the specification. My thoughts are as follows: * I almost laughed when I saw the irrelevant attribute. First, because that's a word that web developers throw around a lot and second because I can't imagine ever using it. The spec says, When specified on an element, it indicates that the element is not yet, or is no longer, relevant. User agents should not render elements that have the irrelevant attribute specified. If it's not relevant, why is it in the page in the first place? Further, do you know how many people will spell this wrong 100 times before they spell it right? Unless there's a deeper meaning or requirement behind this attribute, I think it's just a waste of a section. * The scoped attribute is a welcome addition to the style/ element. Being able to apply styles to just a section of the page is something that I've personally struggled with mightily. I'm glad to see a logical solution. * I'm not sure what the section/ element offers over the div/ element. I thought the purpose of the div/ was to indicate a section of the page. If there's not a clear distinction between these elements, I don't see the need for a second one. * I like the nav/ element. It's helpful in a number of ways to have an area marked as being for navigation. The accessibility implications alone are outstanding. * I'm a bit unsure of the article/ element. As with section/, it seems only vaguely different from div/ and too focused on solving the question of what markup to use for a blog. * The aside/ element really pushes the boundaries of marking up literary devices. I'm not sure enough web developers know what an aside actually is. Short asides are typically indicated by parentheses and I don't see any reason not to keep doing that (seriously). Any element that requires someone to ask an English teacher when it should be used is probably a bad idea. * I understand the concept of the dialog/ element but it's named completely wrong. The point is to markup a conversation between two or more parties. The problem is that the word dialog, when in used in user interfaces, refers to small windows that can be interacted with. When I first read about this element, I assumed it was a way to indicate that part of the page is a dialog window outside of the normal flow of the document (which I thought was cool). After reading the rest, I was disappointed to find out that wasn't the intent. I'd rename this element as conversation/ or discussion/ to avoid such misunderstandings. * The ping attribute on the a/ element is a stroke of pure genius. We've been left hacking solutions for click monitoring for way too long. * The dfn/ is another that stresses the understanding of grammatical structure for web developers. The intent is to designate the defining instance of a term, abberviation, or acronym. Does that make sense to you? If it did, give yourself one point; if it didn't, don't feel bad, most people won't get it. Again, any element that leaves people scratching their heads probably isn't necessary or useful. * Speaking of confusing, I've read the section about the meter/ element five times now and still have no idea what it's used for. * The video/ and audio/ elements bring some much-needed sanity to the embedding of media into web pages. * The async attribute is a welcome addition to the script/ element, allowing it to perform non-blocking code execution. Realistically, this is useful only for a small number of JavaScript files as there are often dependencies between JavaScript files. The entire specification is insanely long and, interestingly, covers much more than just markup. It also covers related and unrelated DOM interfaces as well as additional JavaScript APIs. I think it's heading in the right direction, but HTML 5 does miss some things that seem to be issues that should be addressed: * I'd like to see some treatment of rich text input controls. Right now we all use a hack (an iframe in design mode) that has to be copied over into a form field to be submitted. It would be nice to have this handled natively and have reliable HTML formatting of that content (instead of the per-browser implementations we have now). * I'd like to see a common attribute that can be used on any element to indicate information related to the element. I'm tired of fighting the custom attribute battle. The fact is that it's a very common need to include extra data
Re: [whatwg] Thoughts on HTML 5
[EMAIL PROTECTED] wrote: Lachlan had commented that irrelevant could be changed dynamically to indicate parts of an application that may be relevant only during particular points in time. I don't see how this is any different from hiding content that isn't necessary. Presumably a non-visual UA could use the irrelevant attribute to distinguish content that was not relevant at the current time from content that was merely being hidden from graphical UAs. I seem to remember (but I am far from being an expert) that currently aural browsers ignore display:none content and so best-practice for adding additional text for aural UAs is to use CSS positioning to move it out of the viewport. @irrelevant seems to provide a way to move away from this kind of crazy hack. -- Eternity's a terrible thought. I mean, where's it all going to end? -- Tom Stoppard, Rosencrantz and Guildenstern are Dead
Re: [whatwg] Thoughts on HTML 5
Screen readers currently ignore elements with styles of display:none and visibility:hidden. In order to hide elements from the screen but allow screen readers to see them, we typically use tricks such as text-indent:-1 and such. I would like something to indicate that text should not be rendered by the UA but still remain accessible. Content that should be available to screen readers but not have a visual representation is, in fact, relevant. It's relevant in that it gives additional information to non-sighted users that is probably visually indicated to those who can see. If accessibility is the point of the irrelevant attribute, then it fails. -Nicholas [EMAIL PROTECTED] wrote: Lachlan had commented that irrelevant could be changed dynamically to indicate parts of an application that may be relevant only during particular points in time. I don't see how this is any different from hiding content that isn't necessary. Presumably a non-visual UA could use the irrelevant attribute to distinguish content that was not relevant at the current time from content that was merely being hidden from graphical UAs. I seem to remember (but I am far from being an expert) that currently aural browsers ignore display:none content and so best-practice for adding additional text for aural UAs is to use CSS positioning to move it out of the viewport. @irrelevant seems to provide a way to move away from this kind of crazy hack. -- Eternity's a terrible thought. I mean, where's it all going to end? -- Tom Stoppard, Rosencrantz and Guildenstern are Dead
Re: [whatwg] Thoughts on HTML 5
[EMAIL PROTECTED] wrote (with snippage): * I understand the concept of the dialog/ element but it's named completely wrong. The point is to markup a conversation between two or more parties. The problem is that the word dialog, when in used in user interfaces, refers to small windows that can be interacted with. When I first read about this element, I assumed it was a way to indicate that part of the page is a dialog window outside of the normal flow of the document (which I thought was cool). After reading the rest, I was disappointed to find out that wasn't the intent. I'd rename this element as conversation/ or discussion/ to avoid such misunderstandings. I was confused by the name of the dialog element in exactly the same way you were, originally thinking it was to do with pop-up dialogue boxes. The HTML 4 spec states: Another application of DL, for example, is for marking up dialogues, with each DT naming a speaker, and each DD containing his or her words. ... which I presume influenced the addition of this element. If there is a lot of dialogue marked up on the Web it deserves its own element, if not I guess DL could be considered to stand for dialogue list in addition to definition list. * I'd like to see a common attribute that can be used on any element to indicate information related to the element. I'm tired of fighting the custom attribute battle. The fact is that it's a very common need to include extra data related to an element. I'd propose a reldata attribute (short for related data) be considered as an optional attribute on all elements. We then, as developers, could use that attribute as we see fit and the document would still validate (for people who care about such things). I'm not entirely sure I understand, but if you want to further define the semantics of an element or make it more specialised, another group has put forward the idea of a role attribute http://www.w3.org/TR/2007/WD-xhtml-role-20071004/. Regards, Dave
Re: [whatwg] Thoughts on HTML 5
Yes, I believe the dialog/ element is supposed to be a disambiguation of the
dl/ element, which has previously been used for both conversations and
definition lists. It makes sense to have separate ones since there's no way to
tell what a dl/ represents now. That being said, I still feel the tag name
dialog is too confusing to use. Perhaps the role attribute would be
appropriate to use on dl/, such as dl role=conversation/?
As for my suggestion of reldata, my intent is to use the attribute for any
type of data related to the element. The role attribute is intended to be
used (from my understanding) to designate what role the element is playing on
the page. This is not an appropriate place to put extra data that isn't
necessary for the rendering or understanding of the element. My thought is
doing something like this:
div id=whatever reldata={clicks:1,track:true}
The data format could be whatever someone wants, plain text, structured text,
JSON...whatever you need. The point is to have a common place to dump extra but
related data that isn't important to the understanding of the element. I often
use custom attributes for this now, but it would be nice to have an official
attribute for this purpose.
-Nicholas
[EMAIL PROTECTED] wrote (with snippage):
* I understand the concept of the dialog/ element but it's named
completely wrong. The point is to markup a conversation between two or more
parties. The problem is that the word dialog, when in used in user
interfaces, refers to small windows that can be interacted with. When I first
read about this element, I assumed it was a way to indicate that part of the
page is a dialog window outside of the normal flow of the document (which I
thought was cool). After reading the rest, I was disappointed to find out that
wasn't the intent. I'd rename this element as conversation/ or discussion/
to avoid such misunderstandings.
I was confused by the name of the dialog element in exactly the same
way you were, originally thinking it was to do with pop-up dialogue
boxes. The HTML 4 spec states:
Another application of DL, for example, is for marking up
dialogues, with each DT naming a speaker, and each DD containing
his or her words.
... which I presume influenced the addition of this element. If there
is a lot of dialogue marked up on the Web it deserves its own element,
if not I guess DL could be considered to stand for dialogue list in
addition to definition list.
* I'd like to see a common attribute that can be used on any element
to indicate information related to the element. I'm tired of fighting the
custom attribute battle. The fact is that it's a very common need to include
extra data related to an element. I'd propose a reldata attribute (short for
related data) be considered as an optional attribute on all elements. We
then, as developers, could use that attribute as we see fit and the document
would still validate (for people who care about such things).
I'm not entirely sure I understand, but if you want to further define
the semantics of an element or make it more specialised, another group
has put forward the idea of a role attribute
http://www.w3.org/TR/2007/WD-xhtml-role-20071004/.
Regards,
Dave
