Re: [whatwg] New attributes would degrade better than new elements
Hello all The main discussions missing from this thread is the actual semantic meaning of especially . First of all, the semantic value should be conveyed to assistive technologies. Before that is happening I'd say it is NOT implemented in any really usable fashion by browsers. AFAIK some browsers fail this, even though they are listed as supporting on caniuse. That being said, I think some browsers, at least Firefox if memory serves me correctly, do in fact work with screen readers and dropping the elements in favor of attributes would require some substantial rework of those browser engines. However, is also sectioning content, but and are not (2nd point). Making such a distinction based on an attribute sounds like a recipe for disaster to me. That being said, AFAIK there is no single browser, server side script, client side script or other parser known to me that actually honors the sectioning algorithm in HTML5 completely, so making a spec change now would not break things up too much. Thus, nothing is really implemented yet. Summary: We should not discuss this issue as if it's only a matter of styling. However, I prefer having elements to attributes for nav, header and footer. My experience as a teacher is that it is preferable to have a 1:1 mapping between elements and semantic meanings. That was my main point when arguing that should be dropped. It alters semantic meaning based on position and that is plain wrong. Adding semantic meaning using attributes is slightly less wrong, but still flawed. Even if IE 7 and 8 will persist for a few more years, HTML5 will affect the web for decades and there is a limit to how much the future should be affected by mistakes of the past. 2011-10-26 21:38, Jukka K. Korpela skrev: New elements like and have the problem that some existing user agents don't recognize them, even for the purposes of styling. So if you want to use , then - unless you're using it for purely semantic reasons with no idea of styling - you need to use some special trick to make old browsers recognize it or assign your styles to some logically redundant markup that you use in addition to . Therefore, it would be much simpler, for compatibility with existing user agents, to use just and . Such elements can be styled at will, and if any browsers or search engines wish to recognize semantic markup, type=nav should not be a bigger problem than , rather smaller. I understand that this should have been suggested years ago. But I didn't think of the issue, and it seems that neither did anyone else, aloud. And it's not too late, is it? Nobody needs new elements with no required functionality, really. The idea of more compact markup is pointless. People don't read or write markup that much, and if they do, is no less semantic than . But the latter has the serious drawback of being ignored by many relevant user agents. It does not need to be the 'type' attribute of course. That attribute name is seriously overloaded, so 'kind' might be better. The important thing is to introduce an attribute different from 'class', which currently lets authors use a free naming space. We don't want to interfere with style sheets that might use this or that 'class' attribute value; instead, a new attribute name (defined as semantic, not presentational, but still useful for styling) is called for - rather than new element names, which are born homeless. -- Keryx Web (Lars Gunther) http://keryx.se/ http://twitter.com/itpastorn/ http://itpastorn.blogspot.com/
Re: [whatwg] New attributes would degrade better than new elements
2011-10-30 00:18, Eric Sh. skrev: I heard there are plans to create new tags for layouts to replace the use of tables as layout elements. You have heard exactly what? Where? Spoke by whom? That would certainly be very controversial! -- Keryx Web (Lars Gunther) http://keryx.se/ http://twitter.com/itpastorn/ http://itpastorn.blogspot.com/
Re: [whatwg] fieldset
2009-10-17 12:04, Ian Hickson skrev: A rider suggestion: expose in the page outline as the heading for the. I considered this, but I don't really want to make the algorithm any more complicated, and I'm not really sure we'd want that exposed, any more than you want the headings for individual inputs exposed, in the page outline. And such a move might also have unintended consequences for accessibility. AT do give legend in fieldsets a special treatment that headings do not get. Without careful dialogue and user testing, we should *not* change the meaning of legend. However, does not this open up the possibility of getting rid of dt/dd in details and use an hx element, which is a much better solution from a semantic POV? -- Keryx Web (Lars Gunther) http://keryx.se/ http://twitter.com/itpastorn/ http://itpastorn.blogspot.com/
Re: [whatwg] The new content model for breaks rendering in MSIE5-7
2009-10-03 21:47, Tab Atkins Jr. skrev: Well, no amount of proof would do so; only a convincing enough argument. I, personally, do not feel that's semantics change between and. Nor do I feel they have different syntax at all - and do have slightly different syntaxes, but it's very minor and pretty much bound up in the fact that has multiple name/value pairs while has only one, so doesn't *have* to worry about ordering in the same way that does. > > etc In what way is the SYNTAX different? We seem to agree on this: First and foremost, in the order is all important. Here it would not matter. In one may have several for each (or several 's in a row), here one may not. You call this "minor", I say confusing. But we have in fact created a new syntax - why is that better than creating new elements? In what way is the SEMANTICS different? > So, in my mind, / do *not* hold some special meaning that > locks them into only ever being used in . is a heading > element, nothing more, effectively equivalent to *. Well, that is not what the SPEC says is it? > I mean, would you complain about using or or > or ... in ? Yes, I would. I am arguing in favor of introducing a new element, which would be the zero cost solution, since is new anyway. + No hacks besides those that we already use to get details working as such in legacy browsers. + When implementing details the browser vendors will not have a harder time using a new element than they would using dt/dd. + We would keep the several meanings per element count down, which from a teachability POV is more important than keeping the total number of elements down. And from that POV nuances are often harder to pick up than anything else. -- Keryx Web (Lars Gunther) http://keryx.se/ http://twitter.com/itpastorn/ http://itpastorn.blogspot.com/
Re: [whatwg] The new content model for breaks rendering in MSIE5-7
2009-10-03 00:51, Tab Atkins Jr. skrev: / only have parsing problems in IE6 and IE7. Both of them *are*, finally, actually dropping off the radar. Windows 7 will accelerate this as people upgrade with an OS that runs IE8 by default. Give it 2 years or so and most places will be able to justify ignoring IE7 (many/most sites already ignore IE6). The IE6/7 problem is not the only one. A number of people, myself included, have expressed dissatisfaction from a semantic and teachability viewpoint. It is not better to let dt/dd have three (or perhaps 2) different meanings, and different syntactic rules depending upon the parent element than it would be to have 2 more elements. And if the use cases for details and/or figure is so weak, that they would be dropped JUST BECAUSE they would introduce yet 1 or 2 additional elements to make them work, than we might as well drop them. Do it right or do not do it at all! If an element has (1) a whole new semantic meaning in one place than it has in another place, and (b) different syntactic rules in one place than it has in another place, it is NOT THE SAME ELEMENT by definition. Let's not kid ourselves. We ARE introducing new elements here. It just so happens that they share the same name as 2 old ones. Or at least the same abbreviated name, since some people suggest that they would be expanded to "details type" and "details data", when used with details. What further proof do you need to understand that we are de facto introducing new elements, even if we confusingly, re-use old names? -- Keryx Web (Lars Gunther) http://keryx.se/ http://twitter.com/itpastorn/ http://itpastorn.blogspot.com/
Re: [whatwg] The new content model for breaks rendering in MSIE5-7
2009-09-29 21:53, Dean Edwards skrev: Can't we just invent some new elements? We've already created 20 new ones. Two more won't hurt. :) This has been discussed on the HTML5 WG list to death. - figure IS new - details IS new BUT over a few peoples dead bodies it seem, that we should add one or two new elements to make them work that would be: - intuitive and easy to teach - semantically clear and that would have: - zero technical problems - no added costs for browser makers to implement, since it would be done in conjunction with figure and details as such anyway Instead we have a "solution" that: - currently requires weird and fragile hacks - redefines the semantics of existing elements Just because adding elements is "evil". I actually do not know what argument that could sway peoples minds on this issue. It is beyond reason to me. I mean, it is not as if the dt/dd had been carefully discussed and researched BEFORE it entered the spec... Something I thought was a criterion for inclusion. -- Keryx Web (Lars Gunther) http://keryx.se/ http://twitter.com/itpastorn/ http://itpastorn.blogspot.com/
Re: [whatwg] The new content model for breaks rendering in MSIE5-7
2009-09-29 19:10, Dean Edwards skrev: There is a nasty side effect though. As you mentioned the document.write() should be the last thing in the . If there are any scripts following the document.write() then they are *not executed*. I consider this a serious drawback. With server software generating script elements all over the place there are bound to be problems with this technique. It would be nice to find a better solution. I consider this a deal breaker. Fragile and unintuitive hacks, that really no one knows or can explain why they work, is NOT the kind of things we should rely on when pushing for HTML5. -- Keryx Web (Lars Gunther) http://keryx.se/ http://twitter.com/itpastorn/ http://itpastorn.blogspot.com/
Re: [whatwg] article/section/details naming/definition problems
2009-09-16 16:27, Jeremy Keith skrev: All s are s but not all s are s Just to be clear: Does that include the rules for headers when articles are nested, or when an article is contained in a section? E.g. would this structure be treated as an identical flow from a headings level perspective if all article tags where replaced with section tags? I.e. Would it be as if I'd use h1, h2 and h3 today? ... -- Keryx Web (Lars Gunther) http://keryx.se/ http://twitter.com/itpastorn/ http://itpastorn.blogspot.com/
Re: [whatwg] article/section/details naming/definition problems
2009-09-16 12:03, David Workman skrev: think 'article' is more suitable than 'post' or 'entry' semantically. I am thinking about the mental model, more than pure semantics. Maybe a *comparison* to entry in Atom and item in RSS in the non normative text could be beneficial? -- Keryx Web (Lars Gunther) http://keryx.se/ http://twitter.com/itpastorn/ http://itpastorn.blogspot.com/
Re: [whatwg] article/section/details naming/definition problems
2009-09-16 03:08, Ian Hickson skrev: I'd like to rename, if someone can come up with a better word that means "blog post, blog comment, forum post, or widget". I do think there is an important difference between a subpart of a page that is a potential candidate for syndication, and a subsection of a page that only makes sense with the rest of the page. Cheers, Has "entry" been discussed? (Shamelessly stolen from Atom.) -- Keryx Web (Lars Gunther) http://keryx.se/ http://twitter.com/itpastorn/ http://itpastorn.blogspot.com/
Re: [whatwg] Make quoted attributes a conformance criterion
On 2009-07-26 03:56, Aryeh Gregor wrote: There's no substitute for real escaping here. What if the developer decided that a better value is something like: Please enter your "login" name here Who is talking about substitution? I am not talking about server side scripting practices as a whole. I said that escaping is no substitution for using quotes, since one can not expect developers to escape space characters. That's all. Or whatever. If you're not sure what the input is, you have to programmatically escape it. Once you're programmatically escaping it, your escaping function can add the quotes, and can add them only when necessary (or always, or whatever you prefer). And I think adding quotes is better handled in the presentation logic, than in the business logic. It is more the responsibility of the front end engineer, than of the back end developer. But it really does not matter. There should be an easy way to enforce it, no matter what code generates the quotation marks. I don't think such an enforcement is a panacea to all problems, but it's a small help for some problems, quite common for rookies, though. Please do not argue against it on the failed merits of not being able to substitute indata filtering and output escaping. Those factors are not part of this equation. I think my suggestion is totally analogous to e.g. semi-colon insertion in ECMAScript. JSLint demands that those should be present, and I've yet to hear anyone say "it's a matter of style". Well, I'm going to say it's a matter of style there, too. The dominant convention in Python, for instance, is to omit semicolons. So, you are using python, a language that enforces specific indentation to define block statements, to say that JSLint has got it all wrong? Douglas Crockford, and every other JavaScript guru I know, have identified using semi-colons as best practice - for JavaScript. My analogy was simply this: Just like it makes sense for a JavaScript lint tool to enforce semi-colons, it makes sense for an HTML conformance checker to enforce quotation marks. Always? No, not for boolean attributes and *perhaps* not for attributes that by design never can take anything but a simple keyword or integer as a value. I think I've stated my case by now. So until I hear from Ian (who writes the spec) or Henri, who is authoring the validator, I think we've reached the end of this discussion. -- Keryx Web (Lars Gunther) http://keryx.se/ http://twitter.com/itpastorn/ http://itpastorn.blogspot.com/
Re: [whatwg] Make quoted attributes a conformance criterion
On 2009-07-26 06:56, Mike Shaver wrote: And yet, tons of inline event handler attribute values on the web omit their trailing semicolons...as a matter of style. Yes, one of 1000 perhaps violates JSLint rules on purpose. But I'd wager my right arm that the overwhelming majority using inline event handlers simply do not know or care about best practices. They are following bad and outdated advice. They probably browser sniff too, or still check for support for document.layers. Or have Visual Studio generate all the ghastly code using default settings, including 40 kB viewstates. And use font tags. Mike, I know what you are doing at Mozilla, and have a ton of respect for you. But I fail to see how you could misunderstand my analogy to JSLint. Or do you suggest that Doug Crockford should drop manual semi-colon insertion from that tool? Commenting on this thread as a whole now: Three kinds of attribute values have been identified: - Those that can have multiple words, e.g. class, alt, title, value... - Those that can have just one word or an integer, e.g. width, length... - Boolean attributes, that can be shortened in HTML. Today teachers like me use (false) XHTML to enforce quotation marks for all three cases, because we've seen the pedagogic benefit (and frankly grown tired of looking over the shoulders of our students and say for the millionth time "you've forgotten to quote that alt attribute value"). I actually thought that having a tool that could enforce XHTML-ish rules for the first (and perhaps second) category above, while still leaving boolean attributes alone, would be seen as a benefit, not as a burden. -- Keryx Web (Lars Gunther) http://keryx.se/ http://twitter.com/itpastorn/ http://itpastorn.blogspot.com/
Re: [whatwg] Make quoted attributes a conformance criterion
On 2009-07-25 05:55, Bil Corry wrote: it's still a best practice to encode/sanitize the value Speaking (once again) as someone who has had students in this position a lot of times (and myself a few times) this does not cover all use cases. Consider this PHP template: Value is the suggested text, if no user data is available it says "login". Otherwise its the users login name (no spaces allowed). All is well. One day a developer decides that "login name" is a better value, and hard codes it into the PHP business logic, producing this HTML: All of a sudden you *effectively* have produced this: And it stops working. Now, what would have been easier to avoid this? Url-encoding hard coded variable data, or adding two quotation marks to the template? Bottom line: I think my suggestion is totally analogous to e.g. semi-colon insertion in ECMAScript. JSLint demands that those should be present, and I've yet to hear anyone say "it's a matter of style". Omitting semi-colons is a known cause of trouble in ECMAScript. Omitting quotation marks is a known cause of trouble in HTML. Choosing between robustness and saving a few bytes, one should always opt for the former. -- Keryx Web (Lars Gunther) http://keryx.se/ http://twitter.com/itpastorn/ http://itpastorn.blogspot.com/
Re: [whatwg] Make quoted attributes a conformance criteria
On 2009-07-23 20:32, Eduard Pascual wrote: While I don't consider a hard requirement would be appropriate, there is an audience sector this discussion seems to be ignoring: Authoring Tools' developers. IMO, it would be highly desirable to have some guidelines for these tools to determine when they*should* quote attribute values. There is one further rub. Code that initially has been made by authoring tools have a tendency to wind up in some front end developers lap, to be amended and/or fixed manually at a later stage. That is even more a reason for a strong recommendation about quotes. Furthermore, I doubt that most people on this list did read my blog post I included as an URL when starting this discussion.[1] In that post I talked about a common scenario. One developer works on the business logic. It puts out attribute values. Another developer works on the presentation logic. He makes templates. Dev 2 omits the quotes and for a long time it might work, since the business logic in question only produces single word values. Then there might come a change, because dev 1 - or the users of the CMS - suddenly starts to produce longer values. Suddenly things break, and since nobody touched the presentation logic code, it might not be the first place where the developers look for an error. And believe me, lots of back end devs are absolutely clueless about front end issues! Yes, they might skip validation completely, but at least such a rule of thumb can be implemented more easily into their work flow. I also note that no one who has spoken against my suggestion claims to have any teaching experience. I see 4 effects that my suggestions might have: 1. Dismiss completely. 2. No new wording, but change the code examples. 3. Add some words about best practice, but do not enforce quotes as a conformance criterion. 4. Go all the way and do just that. The scientific evidence in favor of my suggestion might be quite easy to pick up. Just ask any standards aware teacher how common it is that not using quotes messes up students code! Stopping before (4) above will force people like me to keep requiring false XHTML from my students. My main concern is that in HTML 5 we get lots of new boolean attributes, like "required" on inputs or "maxlength" on textareas, and having to write things like 'required="required"' will make the code longer and messier, since a normal input element might span 2 or 3 lines. Of course this can be settled if we get a tool like JSLint, that can enforce a voluntary stricter check (Crockford's "good parts"), but please note that ES 5 introduces a concept of "strict" rules. This means that ES 5 will be in a similar position to HTML 5, having a lax rule set about what browsers must be able to do, and a strict "conformance critera" like rule set that authors are encouraged to follow. Perhaps this could be solved by simply adding an option to the validator: "Do not allow unquoted non-boolean attribute values". Henri Sivonen, are you reading this? -- Keryx Web (Lars Gunther) http://keryx.se/ http://twitter.com/itpastorn/ http://itpastorn.blogspot.com/ 1. http://itpastorn.blogspot.com/2009/07/value-of-false-xhtml.html
Re: [whatwg] Make quoted attributes a conformance criterion
On 2009-07-23 15:32, Kornel wrote: On 23 Jul 2009, at 13:35, Keryx Web wrote: I'd say it is safe to say that using quotation marks for attribute values, always, except perhaps for collapsed, boolean attributes, has been regarded as best practice for a long time now. Speaking as an instructor for newbies, enforcing quotation marks has proven its value countless of times for me and my students. It's not a clear benefit. Unpaired quotation marks can also be a *source* of errors, which wouldn't happen without them: Having dealt with other peoples code a lot (being a teacher) I'd say that problem is exceptionally rare and very easy to spot, put in contrast with the ones arising from not using quotation marks. The proportion is like 100 to 1. Ergo: In real life the benefit is very clear. As for conformance criteria only being about unambiguous parsing: If that is the case we do not need them at all any more, since HTML 5 defines how to handle badly written markup. Just like validation in HTML 4 in reality is more of a benefit to the developer than the browser, since 99% of all errors actually are benign, so conformance criteria in HTML 5 is supposed to primarily help web developers - and authoring tool developers. And speaking directly to Ian H, a few years ago you said on this list that you'd love for the spec to help teachers as much as possible (within the limits of being a spec). My suggested example markup changes is definitely such a help. -- Keryx Web (Lars Gunther) http://keryx.se/ http://twitter.com/itpastorn/ http://itpastorn.blogspot.com/
[whatwg] Make quoted attributes a conformance criteria
Hello! I'd say it is safe to say that using quotation marks for attribute values, always, except perhaps for collapsed, boolean attributes, has been regarded as best practice for a long time now. Speaking as an instructor for newbies, enforcing quotation marks has proven its value countless of times for me and my students. I'd say that all of my colleagues in WaSP EduTF would agree on that. Others share that sentiment too: http://twitter.com/burningbird/status/2765482250 (I have in fact written elsewhere that this is actually one of my reasons to use false XHTML: http://itpastorn.blogspot.com/2009/07/value-of-false-xhtml.html) With this in mind I suggest that the spec would be improved in the (below) following ways, and that we open a discussion about requiring quotation marks for all non-boolean attributes as a conformance criterion. Suggested spec edits (some written in a diff-ish way, not all a true diff, though): Section 1.9 Keep: Attributes are placed inside the start tag, and consist of a name and a value, separated by an "=" character. The attribute value can be left unquoted if it doesn't contain any special characters. Otherwise, it has to be quoted using either single or double quotes. The value, along with the "=" character, can be omitted altogether if the value is the empty string. Add: In order to avoid errors and increase readability, using quotes is highly recommended for all non-omitted attribute values. 4.6.8 Second example, where the a-element has been added. -The +The 4.6.9 Twice: -id=whatwg +id="whatwg" 4.6.12 - Radius: 12cm - Height: 2cm + Radius: 12cm + Height: 2cm - Radius: title="centimeters">12cm - Height: title="centimeters">2cm + Radius: title="centimeters">12cm + Height: title="centimeters">2cm 4.8.2.1.7 (Very inconsistent example!) -Rating: Rating: + 4.8.14.1 - - - - alt="Blue triangle."> - coords="450,25,435,60,400,75,435,90,450,125,465,90,500,75,465,60" -href="yellow.html" alt="Yellow star."> + + + + alt="Blue triangle."> + coords="450,25,435,60,400,75,435,90,450,125,465,90,500,75,465,60" +href="yellow.html" alt="Yellow star."> 4.9.11 - English speakers + English speakers 4.10.3 - Lost + Lost -Full name: Format: First Last -Age: -Post code: Format: AB12 3CD +Full name: Format: First Last +Age: +Post code: Format: AB12 3CD 4.10.14.6 - Name: - Essay: - - - + Name: + Essay: + + + 5.4.2.1 - + 5.4.3.1 - +href="manual-fr"> 6.12.3.7 - Topic: rel="help">(Help) + Topic: rel="help">(Help) 6.12.3.8 - - - - - - - - + + + + + + + + 7.6 - + 9.1.2.3 No suggested text, but a rewrite will be necessary if quotation marks becomes a conformance criterion. 9.2.8.4 - + -- Keryx Web (Lars Gunther) http://keryx.se/ http://twitter.com/itpastorn/ http://itpastorn.blogspot.com/
Re: [whatwg] Make Vorbis a baseline codec for
Yet another killer app that uses Vorbis: Spotify! 160kbps for the free service. 320 kbps for the premium one. Of course Apple and microsoft, both being hellbent upon using proprietary technologies and taking every single opportunity they have to leverage any monopoly they have attained[1] will object to Vorbis. The only way to fix this is to get Opera, Mozilla and Google to implement it, and get a lot of content out on the web! -- Keryx Web (Lars Gunther) http://keryx.se/ http://twitter.com/itpastorn/ http://itpastorn.blogspot.com/ 1. Last evidenced by Apple specifically shutting out Palm from iTunes, for no technical reasons whatsoever.
Re: [whatwg] Nested list
On 2009-07-16 09:59, Ryosuke Niwa wrote: I personally like the idea of getting rid of span, div, and all other semantically useless elements but I don't think that's the goal of HTML5. FWIW, div's do have semantic meaning. And what if you really want to style something, but not attach semantic meaning? Or if you want to make your own additional semantics using classes? Keeping span is really a good idea! And: If you don't find them useful, nobody is forcing you to use them. And this discussion is useless, since neither span or div is up for any discussion about exclusion. -- Keryx Web (Lars Gunther) http://keryx.se/ http://twitter.com/itpastorn/ http://itpastorn.blogspot.com/
[whatwg] Link errors in spec
Hi and happy new year http://wiki.whatwg.org/wiki/Differences_from_HTML4#Dropped_Attributes All links here are defective, e.g. #the-area should be #the-area-element etc. Lars Gunther
[whatwg] When should a script be parsed
Hi I am in the process of setting up a test page (informal), from which I intend to make real tests and submit bug reports to Webkit, Mozilla, Opera, etc. http://keryx.se/dev/javascript/javascript-parsing-test.html It is not finished yet. It does nut run at all in MSIE... But a few things are noticeable: Webkit based browsers happily tries to parse scripts after the following tags:
Re: [whatwg] Placeholder option for text input boxes
Kristof Zelechovski skrev: Does the hint display if the input control gets cleared after loading? IMHO, The hint should not disappear on focus. It should remain until a new value is entered. Chris There is one aspect nobody has commented on yet. If this feature - heaven forbid - would be used *instead of* labels, or if the label would be moved into the input field, random characters typed by the user would destroy any explanation of a particular fields purpose. E.g. is present on the page, but no other explanatory text. The user accidentally types in "". How will the user get the hint back? Deleting what has been typed and blurring the field. Good usability? I think not! Lars Gunther
Re: [whatwg] HTML 5 will be ready in 2022
Ian Hickson skrev: The spec itself has little annotation boxes on the left hand side that documents where implementations stand, sort-of. There's also this wiki page: http://wiki.whatwg.org/wiki/Implementations_in_Web_browsers There is also this wiki page: http://en.wikipedia.org/wiki/Comparison_of_layout_engines_(HTML_5) As usual it has to be taken with a grain of salt, but it should provide some idea of the lay of the land. BTW, Gecko had an implementation of the ping attribute they backed out due to spec changes. Is that part of the spec stable enough for them to start working on again? Lars Gunther
Re: [whatwg] Errormessages in forms
On Mon, Jul 21, 2008 at 10:31 PM, Robert (Jamie) Munro wrote: What's wrong with: Instructions Must be a valid value Can an input not have 2 labels? Thomas Broyer skrev: Or even: Instructions Must be a valid value Both of these suggestions lack the precision, the semantics and the flexibility of my suggestion. Vz Thomas B's solution: - What if a designer wishes to have the error messages grouped together on the top of the page, instead of next to the input fields and manages to come up with a solution that is very usable? - For the default UA error messages to be inserted correctly it must honour the classname as a microformat. Since that must be spec'd, it might just as well be a real element. Vz Robert M's solution: - Where would the UA put a default error message, in the first or second label? - How could assistive technologies differentiate between normal instructions and specific errors? Lars Gunther
[whatwg] Errormessages in forms
Now it has been a while since anyone proposed a new element... But I can't remember if this has been discussed in any detail... So here it comes! I suggest that we investigate if an errormsg element could be useful. It should be a sibling element to label and have a similar for-attribute. A simple use case: It is getting quite common to have the following: Instructions Must be a valid value But presentationwise it should be displayed like this: Instructions [ (input) ] Must be a valid value Using today's techniques all solutions come out a bit hackish. CSS 3 layout modules (far into the future) might alleviate some of that, but it will not provide any semantics. By adding a designated element we also gain the possibility of moving the error messages out of the label elements, without loosing their association to the input elements. Design becomes easier and new designs become possible. And by adding a new element the following two additional benefits could be achieved: 1. A default hook for errormessages from the UA. I.e. if a field has an associated errormsg-element the UA knows exactly where to put its messages. Consider this markup: Instructions If a user submits the form with non-valid field and no JS solution intercepts the UA SHOULD look for errormsg-elements and put its error messages there. That means a designer keeps some control even if he relies solely upon the UA's built in handling of invalid form values. 2. Assistive technology can use this additional semantics and it is not hard to imagine how that could lead to better user experiences. For completeness sake this element should be treated just like label in most cases, i.e, if clicked it should fire events, set checkboxes and radiobuttons, etc, just like clicking a label element would. And it would also have a similar function in the DOM. Perhaps the era of adding new elements has passed HTML 5 by, but I thought this could really be useful. Lars Gunther
Re: [whatwg] Thoughts on HTML 5 - dialog
Ernest Cline wrote: The only synonym of dialog that is anywhere near as general seems to be . 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 with a spoken list-like dialog. That would be way too narrow. Lars Gunther
Re: [whatwg] INS and DEL in lists
Henri Sivonen skrev: For various legacy parsing reasons and in the table case for CSS table model reasons, this kind of thing is seriously more trouble for implementors than it is worth. From an implementation cost/benefit point of view, I am against allowing ins/del in more places. But from what I've understood it actually works as expected today (in lists). Not that I've yet tested this exhaustively. Allowing list markup in tables seems to be a nightmare to spec and implement - and teach! Ins and del in tables is no priority of mine either. Lars Gunther
[whatwg] INS and DEL in lists
Some of you might have seen this, but accpording to the original author there was no response. His suggestions make sense to me. I've been there as well. Lars Gunther This is from Thomas Thomassen on WSG's list: I was working on some examples for the use of and . http://www.thomthom.net/blog/2008/03/document-history-viewer-making-use-of-del-and-ins/ As I was working on this I wanted to mark up a list where items had been added and removed. That's when I realised that you can't wrap up or in or elements because , and only allows list items as their direct child. The and then have to be wrapped inside the list item. Item 1 Item 2 Item 3 When I hid the using display: hidden; the list would render something like this: * Item 1 * * Item 3 Because I could wrap up the entire list item, the bullet point would still remain. To me it appears illogical to not wrap the or around the list items when you add and remove items to the list. I'm guessing it's a case where every scenario wasn't accounted for when the specifications was written. (Yes, I know that I could add an extra class to the list item that I wanted to hide, but it's not the point. It shouldn't be necessary.) However, when this scenario presents itself I see it as fine to break the specification and mark it up like this: Item 1 Item 2 Item 3 This seem to render exactly as I expect it to do in every browser I've tested. * Item 1 * Item 3
Re: [whatwg] [HTML5] Accessibility question - SSML
Benjamin Hawkes-Lewis skrev: I think it's a mistake to assume a "accessible" or "screen-reader-friendly" view should be non-interactive. In so far as this is true at all, it's largely a result of web interactivity depending on non-standard widgets. AFAICT, this is one of the problems HTML5 tries to solve. Hear, hear! We also need to work with screen readers and browser developers so that that CSS media rules actually start to be applied. And Webkit should join the ARIA party! A thought (an just a thought), however, that might be worth investigating is if SSML could be embedded into HTML, using similar principles as is being considered for SVG. Lars Gunther
[whatwg] Http-equiv priority
Hi! Reading MS proposal (=decision!) about their new rendering mode switch, I have been very bugged that almost no one has picked up this flaw to be discussed: If a charset is set with a meta-element, it does *not* override the http-header. But If a rendering mode is set with a meta-element, it *does* override the http-header. Is there any precedence for this? If not, I'd suggest that the spec stipulates uniform behaviour. Lars Gunther
Re: [whatwg] scope attribute on td
James Graham skrev: FWIW the HTML 4 behavior which turns a into a heading from the point of view of the UA is, in principle, useful since there are cases (particularly for row headings) where one cell is effectively both data and a heading but the formatting should be data-like rather than heading like. I use TH for those cases and fix the formatting with CSS... To keep the scope attribute for formatting purposes is a really bad argument, IMHO. If an element is "turned into" a heading it should be marked up as a heading. Lars Gunther
Re: [whatwg] simple numbers
Ian Hickson skrev: > > I considered all the feedback on having a element (or similar), quoted below. > > While I think there is certainly something to be said for the proposal, I don't think there is enough evidence that authors really want or need this. I think we should focus on having CSS support this first. > > Thanks for the feedback, though. > FYI and FWIW I have taken this discussion to the CSS WG. http://lists.w3.org/Archives/Public/www-style/2008Jan/0129.html Lars Gunther
Re: [whatwg] Element
Matthew Paul Thomas skrev:
To allow this on the Web, the CSS font-style property would need to have
not just "normal", "italic", and "oblique" values, but also an
"italic-inverse" value. Browsers should then use this value by default
for any inline element where they currently use "italic".
No problem!
i {
font-style: italic;
}
i i {
font-style: normal;
}
/* and to be sure */
i i i {
font-style: italic;
}
i i i i {
font-style: normal;
}
However, on the web nestled em seems to be used mostly to add additional
level of emphasis, for which I think this might not be suitable. And
nestled dfn-tags seem absurd to me.
Lars Gunther
Re: [whatwg] Use cases for data templates?
Apologies, but bump! Keryx Web skrev: Henri Sivonen skrev: * What's the use case for data templates? It is hard to review them without knowing what they are for. Conjecture-based comments/questions follow. I am also very interested in this question. I think there is a tendency to include too much in HTML - "since that what developers know". Except for the case of repeating stuff on a multi-line form (already covered in Web forms 2) I have never felt the need for any client side template system, nor have I read of any app where this might be useful. BTW, will they degrade gracefully? Lars Gunther Who still wants a use case for templates at the front-end!
Re: [whatwg] , , , ; Re: Presentational elements in Web Applications 1.0
Ian Hickson is reading his mail so fast this almost feels like IM ;-) Why is inappropriate? According to HTML5, it's exactly the element you want, in fact. a) To my linguistic senses that's not a paragraph b) I've seen several people use the div-element (like it or not). Should all their work suddenly be called non-conformant? My main example: http://simplyaccessible.org/article/search-form-layout Random examples: http://snipplr.com/view/3675/css-form-template/ Fieldset - div - inline http://www.webmasterworld.com/html/3247326.htm As to my (a) argument. Sometimes I could go with a list, as in http://www.alistapart.com/articles/prettyaccessibleforms Lars Gunther
Re: [whatwg] , , , ; Re: Presentational elements in Web Applications 1.0
Krzysztof Żelechowski skrev: It would also clean up the current situation where the strictness of the BODY element is meaningless because you can wrap all content in a DIV element to make it strict. I use it sometimes for a very small form, where I think or is inappropriate and is overkill. As in Username: Password: I suppose I am not the only one who has made similar constructs. Should they all become non-conformant over night? Lars Gunther
Re: [whatwg] createElement convenience method
Michael A. Puls II skrev:
> On 10/20/07, Keryx Web <[EMAIL PROTECTED]> wrote:
>> If PHP:s convenience additions to the W3C DOM were made standard (and
>> implemented in browsers) it could have been:
>>
>> var link_to_add = document.createElement("a",the_text.nodeValue);
>
> You can do this:
>
> Document.prototype.createElement = function (name, text) ---
Yes I can. And solutions such as this one is how I expect my intended
suggestion to be made available to current browsers until they die out.
The main problem I see is that since JavaScript does not allow method
overloading (?) there is no way to separate between the native
createElement, with one parameter, and the overriding new method. One
must also develop a check for the new two parameter capability to avoid
unnecessary messing with the Document.prototype.
But I do think these things are solvable.
For clarity's sake: I did not suggest this in order to solve my personal
problem today. I think this is a feature that will be of benefit to many!
Lars Gunther
Re: [whatwg] createElement convenience method
Křištof Želechovski skrev: Convenience methods such as the one proposed here should not make it to the standard for the sake of clarity and compatibility; the programmer can reuse an existing wrapper function instead: var link_to_add = createLink(link_text); This approach is safer and saner. Best regards, Chris I beg to differ. Native functions speed things up. My suggestion is both sane and safe as it is. This suggestion falls into the exact same category as getElementsByClassName. A. There are existing functions that has similar abilities. B. This is a very common and repetitive task. C. Adding this won't break any current code. Lars Gunther
Re: [whatwg] Fwd: createElement convenience method
Garrett Smith skrev: try element.textContent Actually I forgot about that one in PHP as I'm sloppily using the mentioned shortcut with nodeValue. They are (in PHP) behaving exactly the same. Lars Gunther
[whatwg] createElement convenience method
Hello again!
I was putting together a page of exercices for my students. It's in
Swedish and mirrored at http://gunther.ne.keryx.se/datagrund-ovningar/
This page must work when delivered from the file system so I can't use
my beloved PHP. However, I missed one feature like crazy. Consider this:
var link_to_add = document.createElement("a");
var link_text= document.createTextNode(the_text.nodeValue);
link_to_add.appendChild(link_text);
If PHP:s convenience additions to the W3C DOM were made standard (and
implemented in browsers) it could have been:
var link_to_add = document.createElement("a",the_text.nodeValue);
What I propose is this second text-parameter to the createElement method
(or a third for createElementNS).
See http://se.php.net/manual/en/function.dom-domdocument-createelement.php
http://se.php.net/manual/en/function.dom-domdocument-createelementns.php
Has the standardization of this functionality ever been discussed? If
so, can someone point me to that discussion?
Lars Gunther
P.S In PHP I can also get the text between start- and end-tags of an
element with
element.nodeValue
instead of
element.firstChild.nodeValue
Even if I've yet to see any bad repercussions from this convenient
shortcut, I could imagine it is a bit more shaky...
Re: [whatwg] Use cases for data templates?
Henri Sivonen skrev: * What's the use case for data templates? It is hard to review them without knowing what they are for. Conjecture-based comments/questions follow. I am also very interested in this question. I think there is a tendency to include too much in HTML - "since that what developers know". Except for the case of repeating stuff on a multi-line form (already covered in Web forms 2) I have never felt the need for any client side template system, nor have I read of any app where this might be useful. BTW, will they degrade gracefully? Lars Gunther
Re: [whatwg] Seeing the open issues
Ian Hickson skrev: In response to the concerns over the lack of transparency that have recently been expressed both in these mailing lists and on blog posts, I have written a tool that exposes the issues I have on my list: http://www.whatwg.org/issues/ I was going to vote for the headers and axis attributes on table cells, but they were not on the list at all. Considering the really strong uproar against HTML 5 from accessibility experts that this issue has caused, I found it surprising to see they were not even considered "an issue". Lars Gunther
Re: [whatwg] My case for Ruby-elements
Ian Hickson skrev: I encourage you to write a blog post about it. http://blog.whatwg.org/ Blog post written! Saved as draft by "itpastorn".
Re: [whatwg] My case for Ruby-elements
Keryx Web skrev: ERGO: The only allowed version of HTML that may be sent to a browser with the text/html MIME-type will be HTML 5. That's a huge benefit to say the least! Correction: Should be "with the text/html MIME-type and ruby support"...
Re: [whatwg] My case for Ruby-elements
Ian Hickson skrev: Yes, I have in fact already begun looking at exactly what the parsing and semantic requirements for will have to be. It should be added to the spec in the coming weeks. May I add that it might be worthwhile to announce this in some noticeable way. Right not HTML5 is taking quite a lot of bad heat, with statements such as "But I really don’t see where HTML5 is better enough" (compared to HTML 4 at http://www.molly.com/2007/08/11/dear-w3c-dear-wasp/ in the comment by Keith Bowes). Simple logic: A. There is no ruby in XHTML 1.0 and no ruby in HTML 4. B. XHTML 1.1 requires an XML-mime type. Which won't be supported by MSIE in any reasonable time frame. ERGO: The only allowed version of HTML that may be sent to a browser with the text/html MIME-type will be HTML 5. That's a huge benefit to say the least! Lars Gunther
Re: [whatwg] My case for Ruby-elements
On topic remark at the bottom... Krzysztof Żelechowski skrev: I have just encountered a similar problem, the difference is my problem is vertical. I have a document in two languages; the document has internal structure (not just plain text). My intention is to display this document in two columns with corresponding passages side by side retaining existing markup. I am afraid there is no way to do it because existing markup cannot span table rows. Not sure if ruby can satisfy that. I am not an expert on ruby in any way. I am not even sure that ruby would be the best solution to my problem, but wanted to throw in the question. With some CSS cleverness it sounds possible to solve your dilemma though. BTW: What do you think about explicit kerning? You can move boxes with a relative position around but the layout depends on their natural positions. I understand this is rather off topic (CSS). Once again, out of my sphere of knowledge. As to the real issue for this list: Can ruby be marked as "todo" on the spec and also commented upon that the use of ruby shall be considered "conformant" for authors? (As of now the only reference to ruby is "Sam Ruby" in the acknowledgments...) Lars Gunther
[whatwg] My case for Ruby-elements
Today, in a private mail Simon Pieters said that HTML 5 will probably get the ruby-elements as well. I had intended to write about this to this list and now simply will ask if this is the case? Personally I have a special use-case. Being a theologian I would like to provide historical documents in an interlinear fashion: Kai ho logos sarx egeneto (Oh, yea, it should be in greek font) and the word flesh became (Literal translation) 2532 3588 3056 4561 1096(Strongs numbers) Imagine this page http://www.studylight.org/isb/bible.cgi?query=joh+1:14&it=nas&ot=bhs&nt=na&sr=1 with proper semantic markup! Of course, we theologians are a small minority of mankind, but the CJK-languages will profit from ruby as well, right? Lars Gunther
Re: [whatwg] element proposal
Anne van Kesteren wrote: We're not enforcing this upon the world ;-) Speaking about enforcing. When this element gets implemented there are a few things I would demand from my browser: 1. That videos should never start to play without my consent. No more bgsound-hellish experiences. Advertisers will protest, but I'd say it is up to them to make their commercials so appealing that I'd want to play the video in question. 1b. If not (1) That video does not play automatically in a window/tab that does not sit in the foreground. I tend to scroll wheel click on links a lot. if there is video content on the page that has just opened behind the one I am currently in and I would like to watch it, I'd definitely prefer to start it when I flip tabs. 2. I would like greater control than just start, stop, pause, forward, back and perhaps moving a slider. Looking at this: http://video.yahoo.com/video/play?vid=cccd4aa02a3993ab06e56af731346f78.2006940 Would it not be great if I could *navigate* to different parts of the video according to some headlines: - Douglas C: opening - Chris Wilson on... - Chris Wilson on... ... - Håkon Wium Lie on ACID 2 - Håkon Wium Lie on the proposed element Etc Instead of relying on notes saying: "So and so starts x minutes into the video". Perhaps some sort of "goto" function with associated labels? Lars Gunther
Re: [whatwg] Using the HTML5 DOCTYPE as a new quirksmode switch
Alexey Feldgendler wrote: There would be replies if your idea was incomplete or controversial, but actually it seems like everyone agrees. What worries me is whether there is a chance that Microsoft actually does what's suggested (and whether someone in Microsoft who is in position to influence this decision actually finds out about this idea and gets convinced). So, has anyone mailed Molly H? Isn't she supposed to work with standards compliance issues within MS? Personally I think the best route to go for MS is to fix all bugs and make "Standards Compliance Mode" truly compliant. And perhaps mimic FFox and have an "almost compliance mode" for transitional doctypes, behaving the same way as FFox of course when they see one. Let's not give MS an excuse to keep behaving badly with HTML 4.01 and XHTML 1! Lars Gunther
Re: [whatwg] Configure Apache to send the right MIME type for XHTML
Benjamin Hawkes-Lewis skrev: When I talked to WebKit developers about this, it seemed they considered their support for real XHTML less reliable than their support for HTML at that point. So while Safari's Accept header may be suboptimal, there's nothing terribly wrong with interpreting it the same as IE and serving it HTML instead. Which means that if I sniff for Safari I will continue to send text/html even when that browser has solved its problems with application/xhtml+xml I see this whole discussion as an exact equivalent of "object detection" vz. "browser sniffing" in JavaScript. I also think it is getting rather off topic You know (X)HTML 5! Lars Gunther
Re: [whatwg] versus xml:base
Simon Pieters wrote: A conforming XHTML 1.0 document must conform to the DTD, which effectively disallows xml:base and a whole bunch of other things (including, say, namespace prefixes). http://www.w3.org/TR/xhtml1/#strict I am moving this discussion to the help list, as it is more about *my* understanding of xml:base than the actual spec. Lars Gunther
Re: [whatwg] versus xml:base
Anne van Kesteren wrote: On Mon, 05 Mar 2007 22:07:03 +0100, Keryx Web <[EMAIL PROTECTED]> wrote: It may be that I've implemented this in the wrong way - corrections are welcome - but it seems to me that even though is legal today, it is **not** supported by UAs. Which makes Anne's proposal, that should be allowed in both serializations, even more important. There's nu such thing as an xml:base element. It's an attribute. And it is supported although there may be some "bugs" with dynamic changes etc. Oh man! I thought it was strange that it did not work in spite having been told that it would by several people on the help list... Well, now all the world knows that I've never before used xml:base in my coding or teaching. But maybe my error in itself illustrates the value of letting be allowed in the XML serialization. The element is known. The attribute is not. No one has argued against allowing the element. Does that mean we have reached consensus? Lars Gunther
Re: [whatwg] versus xml:base
Geoffrey Sneddon wrote: xml:lang and xml:base are the actual attribute names – the XML namespace exists so they work within namespace aware parsers (as XML-Names is a separate spec that extends XML) – therefore, it must be explicitly allowed within the DTD (like xml:lang is). When I read http://www.w3.org/TR/xmlbase/ it seems to me that if a parser understands XML it should be OK to use xml:base. The very last line of that document: "XHTML [XHTML] uses URI references beyond those expressible in XLink. These URI references might be resolved by an application relative to the base URI defined by XML Base. The XHTML specification might want to describe their level of support for XML Base." Apart from faulty grammar in the last sentence I interpret this as "It is a good idea to explicitly state how this attribute is supported." It *might* want to describe this. I think that it would be wise to answer questions such as if both and xml:base are present, which one should "win"? (I've only tested in FFox and the attribute wins over the element.) What authority do you rely on when you say that the attribute must be explicitly allowed? Lars Gunther
Re: [whatwg] versus xml:base
Geoffrey Sneddon wrote:
> XHTML 1.0/1.1 doesn't allow xml:base, though, so is the only >
> way to set a base URL within the document.
In what way would the XHTML 1.0/1.1 spec **disallow** the use of this
element from the xml namespace? It's not *part of* the spec, but that's
a different matter, right?
I've been told is that xml:base should work just fine in Firefox, Opera
and other XHTML-capable browsers, when content is served as
application/xhtml+xml.
OTOH, for this message I decided to do a little test. The following will
be served as true XHTML by my server:
http://www.w3.org/1999/xhtml";>
Testing xml:base
div#msg {
background: pink;
padding: 2em;
text-align: center;
font-size: xx-large;
}
http://dev.keryx.pad/xhtml/css/"; />
Pink background if
is not supported, otherwise light green
In the external CSS I have:
div#msg {
background: lightgreen !important;
}
div#msg:after {
content: " - works! External CSS recognized.";
}
When I try this in Firefox 2.0 it does not work, nor will it in Opera 9.10.
It may be that I've implemented this in the wrong way - corrections are
welcome - but it seems to me that even though is legal today,
it is **not** supported by UAs. Which makes Anne's proposal, that
should be allowed in both serializations, even more important.
Lars Gunther
Re: [whatwg] versus xml:base
Anne van Kesteren skrev: I think should also be allowed in XML documents. It simplifies the language, it already needs to be supported and is able to set Document.baseURI where xml:base can at most set Document.documentElement.baseURI. (Document.baseURI influences how XMLHttpRequest works for instance.) The element section should probably also talk about what happens when you modify the .href attribute. And today the base element already works in at least FFox and Opera also when content is sent as true XHTML 1.0, so this would not really change anything but the spec. Lars Gunther
Re: [whatwg] Should be more general-purpose?
Simon Pieters wrote: > > Ease of use, mostly. It's simpler to say: > >665 3rd St. >Suite 207 >San Francisco, CA 94107 >U.S.A. > > ...than: > > > 665 3rd St. > Suite 207 > San Francisco, > CA > 94107 > U.S.A. > Ïn all fairness, that's not equivalent information. The first is no way near able to be parsed by a machine, converted to vCard, imported into an address book, etc. Microformats provide a granularity and flexibility that make them superior to "raw" HTMl for information like this. Lars Gunther
Re: [whatwg] How to make HTML5 easier to teach (Was: several messages about HTML5)
Henri Sivonen wrote: The semantics for the warnings, errors and fatal errors emitted by http://hsivonen.iki.fi/validator/html5/ are as follows: Warning: Something that I think is harmful but there's no spec that would allow me to call it an error or something that technically conforming bet is extremely likely a mistake made by the author. OR: Something that a spec makes an error in most cases, but determining if it indeed is a spec violation requires inspection by a human. A few examples that I think is bad practice (99.9 % of the time it's used): - Inline styles - Empty p-elements, or p elements containing only - A table within a table cell (Has this ever been used for anything but layout?) - Iframes Would I get a warning for any of these? Lars Gunther
Re: [whatwg] [WF3] Web Forms 3.0 Feature List
More food for thought can be found at http://friendlybit.com/js/improving-interactivity-with-javascript/ At least three of them seem to not be in WF 2: "Drag and drop", "Image handling" and "Sortable Items". Auto validation seems like a usable feature as well, but is perhaps left to JS as server-side validation often is necessary. Lars Gunther
Re: [whatwg] How to make HTML5 easier to teach (Was: several messages about HTML5)
Ian Hickson wrote:
On Sat, 24 Feb 2007, Keryx Web wrote:
If I as a teacher would want anything from a spec, it would be that it said
"this is wrong" and "this is right" in such a way that it becomes an
instrument in grading. --- The
technology must enforce it upon them.
Could you elaborate on this, maybe showing some concrete examples of what
you mean? I'd love to make the spec easier to use for education.
Speaking from __my__ experience, and the experience of those (too few)
colleagues that I've met in Sweden who teach standards based web
development, it is hard too make the student understand that something
is wrong if he/she "get's away with it".
In my case that has led me to demand that all student's who want more
than the lowest grade must use a strict doctype. The only problem with
those doctypes, that are not intuitive, is that inline-level content is
not allowed as children of the form-element. As soon as I explain "well,
that's the rule..." most students do it right.
Since there is a ton of examples claiming to teach best practice that
uses the transitional doctype, I must carefully enforce the
__philosophy__: (S)eparation of content, design and behavior,
(S)tandards compliant code, (S)emantic code. In this process terminology
does matter. I always correct a student that says (designing with divs".
("You are not designing with divs, you are designing with a CSS grid!")
The current tripartite doctypes are a tool. One can explain how things
are "deprecated", that is allowed to ease the transition of existing
material, but really not good to use, and that with the preferred strict
doctype layout without CSS is practically impossible.
I would like the spec to clearly state what is allowed for backwards
compatibility only and what is the preferred way of marking up content.
I would like a spec that clearly says that some ways of marking up
content is detrimental to accessibility and perhaps also usability. E.g.
frames, including the iframe, or tables used for layout. You would not
believe how many colleagues of mine who actually teach that frames are a
good thing. My nephew, who studies i a nearby city, even had frames as a
required feature of his work!
I would also like to see that the conformance checking software would
give me a graded output:
1. Warning - technically allowed but bad practice
2. Error - not according to the spec
3. Fatal error - most browsers will not be able to parse at all
Putting a students work through a validator (be it HTML, CSS or WAI) and
showing that it is not only my personal view, but hard facts, that
influence my grading, makes the students feel more comfortable in what
they are expected to learn and that they receive fair grades.
Of course some things, such as interaction design and aesthetics, are
impossible to grade with a machine. And yes, I know that it is possible
to write valid code that is unsemantic, so one must look at the code
manually as well.
Lars Gunther
Re: [whatwg] several messages about HTML5
Ian Hickson wrote: Probably the best we can do is design the language to make "the right thing" easier, and invest more heavily in education. In this regard HTML is in the same boat as more important subjects; I imagine that as we improve the quality of education in general, understanding of the importance of accessibility and related topics will improve as well. Improving education is easier said than done. My efforts so far has been not too successful: http://www.webstandards.org/action/edutf/interviews/gunther-en/ If I were to add one thing to that interview it would be what I call "educational entropy". The teaching of web design and technologies deteriorates over time, just because time passes. It is a tough job teaching these things, keeping up to date and imparting that knowledge in a pedagogical way. I can share more horror stories than I would like to believe existed. If I as a teacher would want anything from a spec, it would be that it said "this is wrong" and "this is right" in such a way that it becomes an instrument in grading. Most teachers will *not* invest the effort of learning best practices or keeping themselves up to date. Most school leaders will not provide them with enough money to attend good conferences or seminars. The technology must enforce it upon them. At least in Sweden front end web development is seen as an easy subject. There is not one single course that deals with that subject on an advanced educational level. Not one single university offers such a course, not even the ones that offer special programs for web developers! A few years ago Sweden was a leading country in adopting the web. In a few years I suppose we will be seen as the retarded cousin from name of choice>. Lars Gunther
Re: [whatwg] Hermenutics. Was: several messages about HTML5
Benjamin Hawkes-Lewis wrote: Elliotte Harold wrote: Authorial intent is a myth. All communication involves translation, and something invariably gets "lost" in translation. But if you want to arrive at an approximation of what an original interlocutor meant (which is what we usually want to do), you want an interpreter who attempts to capture, however remotely, the original meaning, not somebody who just makes stuff up. Partial knowledge is better than no knowledge. This discussion seems to be more about hermeneutics than technology. Being a theologian I suddenly feel at home and would like to offer my 2 cents. It would be sad to see this effort be lost because partly valid post modern-ish hermeneutic viewpoints, such as is echoed by Elliotte Harold, are allowed to win out over also partly valid viewpoints more in line with modernity - such as echoed by Benjamin Hawkes-Lewis. Modernity gave us a hermeneutic approach almost obsessed with finding the original authors intent. For ancient texts, such as the Bible, this proved more difficult than at first supposed. For this but also for a number of other reasons post modern hermeneutics rightly criticizes the modern approach, but often finds itself lost in a quagmire of relativity and subjectivity. Even if one does not find the original intent in an exact way, it is possible that the effort reveals enough to make some interpretations much more plausible than others. The effort is seldom pointless. Lars Gunther
Re: [whatwg] HTML 5 and PHP
Ian Hickson wrote: In HTML5, the string "" is valid. So the PHP function works fine. :-) OK, I've re-read the discussion from November. My memory was incorrect. _Singleton_ tags are allowed to be "self-closing", it seems... Now that the HTML5 specification has a very clear HTML parser specification, it would be relatively simple for someone to write an HTML5 parser in PHP which can then be used with the XML pipeline. This has already been done with Python, for instance: http://code.google.com/p/html5lib/ The above project also provides a number of test cases: http://html5lib.googlecode.com/svn/trunk/tests/ ...that can be a huge help to any parser implementation project. Although I am quite sure we are going to see some activity concerning (X)HTML 5 on PECL soon, the option of using native XML methods still appeal very much to me. As the spec stands today, I think the discouragement from using "XML on the web" is way to strongly worded. Client support may be faltering, but on the server side XML technologies are very mature and very useful. While it is true that tools are widely available, they aren't widely used, For example, WordPress doesn't support XML natively -- it actually outputs strings, it doesn't have an internal tree representation. This can easily lead to non-XML-well-formed content. Perhaps going off topic here: Wordpress is written in PHP 4. It can not benefit from the best Tidylib, the real DOM-extension, XML Reader, XML Writer or Simple XML. All those extensions require PHP 5. Nor can Wordpress do professional interaction with the DBMS through mysqli or PDO, since those also require PHP 5. Wordpress may be spectacularly successful, but IMHO it's design is a really crappy one. It was at the right time at the right place, but it is not a good example of how to do an enterprise PHP application. There are tons and tons of legacy applications still on the web, written in PHP 4, not to mention bad hosts that are afraid to upgrade, but according to stats from Zend most new development is now done in PHP 5, espoecially if one considers enterprise level apps. Joomla is a better example of an PHP app that slowly is going in the right direction. I would suggest rephrasing --- To something like: | Authors must be aware that XML has much stricter syntax rules than the | "HTML5" variant described above and that true XML parser will choke on | even the slightest error. Unfortunately, saying that authors "must" be aware of something is not often heeded. Authors usually claim to be aware of many things that they aren't aware of, or don't really understand. This is why the spec is currently phrased as just a discouragement. (The word "must" also has much stronger implications than the word "discourage" in spec terminology.) Since I am (among other things) a PHP developer I know all there is to know about sloppy coding... ;-) OTOH I do not believe it's a good idea to patronize developers either. And why would they heed the current "discouragement"? There are, once again IMHO, two major reasons why new sites still have ugly, not valid, un-semantic tag soup code: WYSIWYG tools and CMS-software. I'd suggest that most developers of such software do not consider XML to be an immature technology. They are doing XUL, XAMLL, SOAP, RSS, OOXML, ODF, etc, all day long... Lars Gunther P.S. More off topic: Incidentally: I have a few questions on how HTML 5 might not play nice with PHP. Considering that maybe 90 % of all content on the web is dynamic and that PHP have perhaps 50% of that, this one is a biggy. These numbers don't match the research I have done -- could you elaborate on the methodology you used to obtain these numbers? Based on my own research I would say that 45% is far over-estimating the number of pages on the Web that are generated using PHP. There are lies, damned lies and statistics. This is one of the impossible to know exactly questions. One might consider: Netcraft stats: How many websites report PHP in their server string? That would be more than 50 %. But then, on shared hosts, do people actually use it, and if they do, to what extent? So Netcraft stats are too high. One might consider file extensions. Well, that might work well for ASP, but PHP-developers just love mod_rewrite way too much for this to be reliable. So stats based on file extensions are too low. Where did I get my numbers? I went the middle road, and the exaggerated some for effect ;-) These facts however are __undeniable__ 1. PHP is the most used server side scripting language in entry- and mid-range apps. Perhaps Ruby will take some of that market though. 2. PHP is rapidly gaining acceptance for enterprise level apps, with extensive backing from Yahoo, IBM, et al. 3. PHP is the most used scripting language for the well known "Web 2.0" sites, even ahead of Ruby, and way, way ahead of every other language. Even i
[whatwg] HTML 5 and PHP
Hello again! I have a few questions on how HTML 5 might not play nice with PHP. Considering that maybe 90 % of all content on the web is dynamic and that PHP have perhaps 50% of that, this one is a biggy. 1. PHP has a useful nl2br-function that takes a string and inserts a tag before every newline. http://se.php.net/nl2br If HTML 5 in its HTML serialization actually forbids the self closing slash in the element it will be impossible to use this function for anything but the XML serialization. Has the PHP community been informed on this? Have they replied in any way? 2. Speaking of XML, as of PHP 5 there is a plethora of XML tools available for manipulation of content: A really good DOM implementation (with many convenience shortcuts i miss when scripting JS), Simple XML, XSLT, XML Reader, SAX, XML Writer, etc. Server side it makes very much sense to use the XML serialization and not the HTML one. As the spec stands today, I think the discouragement from using "XML on the web" is way to strongly worded. Client support may be faltering, but on the server side XML technologies are very mature and very useful. Personally, if I get user data, i filter it first through Tidy, then through the strip_tags function, then through XSLT and finally through some custom functions. This way I am ensured of standards compliant valid markup and has a solution that is 99.9 % resistant to XSS attacks. Treating everything as (or with Tidy converting it to) XHTML helps a lot. I would suggest rephrasing: Generally speaking, authors are discouraged from trying to use XML on the Web, because XML has much stricter syntax rules than the "HTML5" variant described above, and is relatively newer and therefore less mature. To something like: Authors must be aware that XML has much stricter syntax rules than the "HTML5" variant described above and that true XML parser will choke on even the slightest error. Lars Gunther
Re: [whatwg] The m element
Alexey Feldgendler wrote: I don't like the idea of reusing an existing presentational element such as . Otherwise we'd immediately have the web full of incorrect uses of the element. I agree strongly. Rule number one: Do not confuse users. Therefore it is bad usability to underline anything that is not a link. Rule number two: Do not confuse developers. If developer A starts building an app using to mean anything else but "underlined text", then developer B comes along, sees all existing markup - gets confused - and it will take quite a while for her/him to get up to speed. The only current element that can be used instead of is , like in , or class="searchresult"> I think that is good enough. We do not need need the element. Lars Gunther
Re: [whatwg] (X)HTML best practice cheat sheet
Keryx Web wrote: Hi I have started to produce a cheat sheet on (X)HTML authoring best practice primarily for my students, to print out and keep by their computer. --- If someone could give me some feedback on this - off > list of course - from an (X)HTML 5 perspective I have moved this discussion to the new what-wg help list, where I do not consider it to be off-topic and replies can be sent to the list. Many thanks to those who have responded to me personally! Lars Gunther P.S. The (now improved) cheat sheets are now located at http://keryx.se/wasp/html_elements_beta.pdf http://keryx.se/wasp/html_elements_beta.ods (Open Office Calc)
Re: [whatwg] Element content models
Michael(tm) Smith wrote - a long time ago: However, I would vehemently stress that it is not that uncommon for notes and marginalia to themselves have notes or marginalia, I don't doubt that there are some, but are you aware of any specific examples? The Talmud! Or most scholarly works of theology. They can have a long trail of notes, and it is very unwise to limit that functionality. Lars Gunther
[whatwg] (X)HTML best practice cheat sheet
Hi I have started to produce a cheat sheet on (X)HTML authoring best practice primarily for my students, to print out and keep by their computer. The unfinished cheat sheet is *temporarily* available at: http://keryx.se/wasp/html_elements_alpha.pdf http://keryx.se/wasp/html_elements_alpha.ods (Open Office Calc) If someone could give me some feedback on this - off list of course - from an (X)HTML 5 perspective, it would be greatly appreciated. Lars Gunther P.s. the url is temporary and will change in a few weeks. PPS to the moderator. I accidentally sent this message from the wrong sender address. Please ignore my first post.
