Re: [whatwg] Text selection in IFrames
At 09:37 -0500 UTC, on 2007-08-09, Devi Web Development wrote: [...] On 8/1/07, Ian Hickson mailto:[EMAIL PROTECTED][EMAIL PROTECTED] wrote: It depends on the platform's conventions. It's not really an interoperability issue as far as I can tell. Not an interoperability issue? One of the main benefits of HTML has been it's device-independence. Ideally, a page should look and act the same in every browser on every platform. Not at all. Ideally a page should look and behave such as is most useful to the user. It might confuse *me* to see multiple selections in a document, but if that's the convention someone else is used to, why confuse him by breaking that? Or why should I confuse you by forcing my convention upon you, when that might conflict with what you're used to? Not to mention all those looks and behaviours that are common in one browsing environment, but simply impossible in another. Frankly, I don't see an application for using user-selected text, but if a script requests the selected text, it should be clear what the script is getting. I would assume that an environment that shows all selections in all iframes is something the user is used to; he'll be fully aware which frame is the active one; and the UA will probably hand the active frame's selection to a script, when the script asks for 'the' selection. (I'm not a javascripter; this just seems logical to assume.) -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [Whatwg] Request for HTML-only print link
At 20:02 +0200 UTC, on 2007-07-28, Sander wrote: Sander Tekelenburg schreef: At 07:12 +0200 UTC, on 2007-07-28, Sander wrote: [...] incosistency makes things harder to use. A print method that works the same across web sites is much more usable. I don't think it's confusing as the browser's own print button is still there. So, people who prefer to use that one still can. Your main argument for a print links seemed to be that some people might not know where to find their UA's print command (hard to believe -- even IE by default presents a shiny print button always). Giving them a print link doesn't help them, because now they still don't know where their UA's print command is. So if you'd really want to help those people, you would not provide a print link. You'd let them figure out how to print, or you could add a help page that explains how to print a web page (making sure that you're clear about which specific browsing environment you''re talking about). Btw, compare with authors providing a back link. I thought there's pretty widespread consensus by now that that's a bad idea. I don't see how a print link is any different. [...] Compare it to the sentence You can find our address on the contact page. From a usability point of view it is advisable to make contact page a link Actually, no, that would be close to click here. You can a href=contact.html#address rel=contactfind our address/a on the contact page would be the more usable markup. (Or alternatively, the entire sentence can be the link.) (Btw, this in turn shows that the sentence was not written for the Web. I understand that this was just a quick example. But it's the sort of text that makes sense in print, but not on the Web. Unfortunately many authors still throw text that was written for print on the Web.) [...] But if you leave it all up to the UA, then it's not all the same for all users, in all cases. So what? If every browsing environment would work and present the same, there'd be no need for more than one browsing environment. The very fact that different people have different needs and preferences is why we have different UAs, why we have separation of content and presentation and why different UAs work differently. It is what makes the Web work. The only thing that's important, if you're talking about usability, is that things work the same for a given user across sites. And per definition, only UAs can provide that experience. -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [Whatwg] Request for HTML-only print link
At 23:02 +0200 UTC, on 2007-07-28, Sander wrote: Sander Tekelenburg schreef: Your main argument for a print links seemed to be that some people might not know where to find their UA's print command (hard to believe -- even IE by default presents a shiny print button always). Well, Opera doesn't show a print button for instance. That only tells you that Opera is aimed at users who wouldn't appreciate an explicit print button. For users who need such a button *and* cannot figure out how to add that to Opera, Opera may not be the best choice of UA. Not a problem. People have other UAs to choose from. Equally so, for users who have no print needs, or for whom file-print, or the keyboard equivalent, is already second nature, having valuable screen space wasted on a print button would not be useful. All Opera's lack of by default showing a print button tells us is that different users have different neeeds/preferences. It confirms that there is no single right UI or document presentation for all users. Giving them a print link doesn't help them, because now they still don't know where their UA's print command is. That's not the point as it is not up to the author of a website to educate their visitors about their browser. Exactly ;) It's up to users to learn to use their tools. (And good tools are as much self-explanatory as possible. At the very least it is the user's responsibility to pick the tool that is easiest to (learn to) use.) [...] So if you'd really want to help those people, you would not provide a print link. You'd let them figure out how to print, or you could add a help page that explains how to print a web page (making sure that you're clear about which specific browsing environment you''re talking about). A lot of site owners just don't want to do that as it turns the focus on the browser instead of their. Well, tough :) Users matter more than authors. (See http://esw.w3.org/topic/HTML/ProposedDesignPrinciples#head-97abe59da6732ca0ab8a6d9d863b100bf1e51266.) So when what authors want to do harms users, it is not a good idea to have HTML cater for those authors. Providing a print link on the spot where you refer to printing doesn't force the visitor to think (which seems to be the credo in usability land). Actually, it does force users to think because they now have to determine the difference between that particular print link and their UA's built-in print function. Look at http://profor.nu/ for example. Activating the UA's built-in print function and activating the print link give different results (at least in Firefox 2.0.0.5 under Mac OS x 10.4.9, printing to PDF). (Yes, I built that site and yes I'm well aware of all that's wrong with it -- blame me for not managing to convince the customer.) Compare it to the sentence You can find our address on the contact page. [...] You're right. It was indeed a quick example. What I meant to say was that providing a link that offers what you're talking about is better than 'just' talking about it. Understood. I'm not sure I see how the comparison makes sense though. Are you thinking of something like We suggest you print this purchase confirmation? Because I'd disagree. You can compare that with we suggest you listen to a href=filename.mp3this exerpt of John Doe's speech/a. Note that it makes no sense to mark that up as we suggest you a href=filename.mp3listena to this exerpt of John Doe's speech. Similarly We suggest you a href=printprint/a this purchase confirmation wouldn't make sense. (Something like this could make sense however: We suggest you print a href=URLthis purchase confirmation/a, if it points to a document that contains the purchase confirmation.) [... differences between browsing environments] So what? If every browsing environment would work and present the same, there'd be no need for more than one browsing environment. [...] What I meant was that people are not always on the same environment. Understod, but web publishers simply aren't in the position to help users with that. Any attempt at that can only result in creating more problems. A good example is suggesting font-size to be 90%, because it helps some users who [A] use IE with its too large default font-size and [B] haven't bothered to learn how to change that default font-size to something that serves their needs. All the web publisher will achieve is make things harder for every other user. As web publishers our first responsibility is to know where our domain starts and where it ends. -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [Whatwg] Request for HTML-only print link
At 05:23 +0200 UTC, on 2007-07-28, Sander wrote: [...] I'd like to see an extension of the hyperlink to give it an HTML-only print function. Nowadays making a print link available from within a website always involves client-side scripting. What is the point of such print links anyway? UAs already provide their own built-in print buttons. Just like they provide back buttons. What's the point of making something that already works the same across different sites, make more difficult for users by making it look/work different on different sites? Btw, I don't understand what HTML-only means. -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] Web forms 2, input type suggestions
At 01:31 +1000 UTC, on 2007-07-16, Lachlan Hunt wrote: Benjamin Joffe wrote: Have the following possible values for the TYPE attribute been considered for the INPUT element? The major problem with all of your proposals is that you have not described any problem that they solve, nor provided any use cases for them. I wrote earlier A use case I can imagine is an authoring tool that let's users create CSS rules. Simply clicking the wanted colour avoids the risk of (syntactically) incorrect color values. Other problems it would solve - works more across browsing environments (because lack of javascript, Flash, etc dependancies). - provides the user with a consistent UI across sites - much less work for authors, not having to write javascript/Flash solutions [...] Here's a few sites I found that ask the user to select colours. http://www.haymespaint.com.au/haymes/colourcentre/ http://www.ficml.org/jemimap/style/color/wheel.html http://wellstyled.com/tools/colorscheme2/ I can't figure out how any of those would benefit from the new input type. [...] All of these are Flash and/or javascript dependant, and thus not accessible in every browsing environment. inpute type='color' would not have that problem (and probably fallback gracefully in environments that cannot present a color picker). All provide their own unique, different UI, which is confusing to users. Users would benefit from a UI that works the same across sites. -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] Web forms 2, input type suggestions
At 21:08 +0200 UTC, on 2007-07-14, Sander wrote: Martin Atkins schreef: Benjamin Joffe wrote: [...] type=color The user agent would display an appropriate colour picker and would send a hexidecimal string represting that colour to the server. I like this idea. It's simple and it's something I've implemented (and seen implemented) dozens of times. I like this one too. Same here. A use case I can imagine is an authoring tool that let's users create CSS rules. Simply clicking the wanted colour avoids the risk of (syntactically) incorrect color values. However, to make it complete it would have to work both ways: if the form defines a color (input type=color value=#66f), that colour should be presented s selected by the UA's color picker. Perhaps that's something to leave entirely up to the UA, but I'd like it better if the at least suggests that they may do. I wonder what the fallback mechanism should be though. What should UAs that do not/can not provide a color picker do? Some testing (iCab, Opera, Firefox, Safari) sugests that UAs that don't support type=color would simply dislplay the value in a text field. If that's true for all legacy UAs, that'd be OK I suppose. It should have an pallet attribute that defines the color pallet. I'm not shure how though Could be useful if you'd need to allow the user to choose only from a limited list of options, yes. If there already is a standard that describes colour palettes, that might be useful. If not, this might be too complicated. -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] Content-Type (was Style sheet loading and parsing
At 16:42 +1200 UTC, on 2007-05-27, Matthew Paul Thomas wrote: On May 23, 2007, at 2:05 PM, Sander Tekelenburg wrote: [...] The argument for using file name extensions is that they can provide a clue as to what sort of file is being pointed to [...] http://urlx.org/google.com/0a8e8 is a URL without a suffix, which is quite understandable, because the whole point of urlx.org is to make short URLs. It redirects to a Google Cache URL ending in .pdf, which is quite understandable, because it's a cache of a PDF document. But the cached version itself is HTML. Yeah, that's what I said in the next paragraph ;) -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] One document or two?
At 17:56 +0100 UTC, on 2007-05-24, Nicholas Shanks wrote: Various people have expressed opinions in favour of either one spec to rule them all, or two specs for different audiences. Is not the simplest solution to have two views upon the same spec? Yeah, that's the idea behind Simon Pieters' User Style Sheet: http://html5.googlecode.com/svn/trunk/author-view-of-html5/. It would be better if that wouldn't have to be such a hack though; if the spec itself would be marked up to allow reliable targeting through CSS. (For instance, Simon's CSS currently hides nothing at http://www.whatwg.org/specs/web-apps/current-work/multipage/section-content-type-sniffing.html#content-type-sniffing, which doesn't seem to be aimed at web publishers.) It would also be better if that Style Sheet would be provided as an alternate, directly from the spec itself. I cannot judge how much work this is. But I think it would be very valuable, because it would make it much easier for many people to review the spec, which would lead to less confusion over what is meant, and thus easier discussion. -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] Style sheet loading and parsing (over HTTP)
At 22:59 +0200 UTC, on 2007-05-23, Julian Reschke wrote: [...] Minimally, every time HTML5 requires recipients to ignore the content type, it should also remind content authors that they should supply a proper content type nevertheless. What would be the point, if UAs are required to ignore it? -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] One document or two?
At 18:43 + UTC, on 2007-05-24, Ian Hickson wrote: [...] It's been considered and might even happen. It's a MASSIVE amount of work, though. For example, it's also not always clear how to categorise the text. What would you do with: pIf a codedl/code element contains only codedd/code elements, then it consists of one group with values but no names, and the document is non-conforming./p Should that be shown in the cut down author version? Yes. Everything that tells authors how to ensure conformity should be presented to them. I think it's mainly the stuff that tells UAs how to handle non-conforming documents that authors generally don't need. There are also a number of sentences that would need to be rewritten so they still make sense with parts of the sentences hidden. Can you point to an example of where you think this would be necessary? My impression was that we're talking mostly about blocklevel content -- hiding paragraphs or even sections. If it would be necessary to mark sentences, or even parts thereof, and to rewrite content, then indeed that would be a hell of a job. But even then I think it would already be a huge improvement if that content were left as it is for now, and to begin with marking only block level stuff that can easily be identified as 'obviously relevant to UA implementoirs only'. Btw, by taking the CSS approach (one spec; different presentations), during the spec's development you could use a Style Sheet that merely sets content apart, not outright hide it. Just like Simon did. It seems likely to me that, because that makes this so visible, people will provide plenty of feedback when something should be shown to/hidden from authors. I don't think this needs to be pixel-perfect, definitely not from the start. Begin by marking what is obviously not needed by authors. From there it will get clear how much more detailed this should be done, if it all. -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] One document or two?
At 00:38 + UTC, on 2007-05-25, Ian Hickson wrote: On Fri, 25 May 2007, Sander Tekelenburg wrote: [...] pIf a codedl/code element contains only codedd/code elements, then it consists of one group with values but no names, and the document is non-conforming./p Should that be shown in the cut down author version? Yes. Everything that tells authors how to ensure conformity should be presented to them. I think it's mainly the stuff that tells UAs how to handle non-conforming documents that authors generally don't need. But the second line quoted above is a UA thing. It's nothing to do with authors. So it's not clear to me that it is as simple as you say. While authors may not understand that second line, they would easily understand the sentence as a whole to be saying that a dl containing only dds is non-conforming. However, looking at http://www.whatwg.org/specs/web-apps/current-work/multipage/section-lists0.html#the-dl, I now see the context. The paragraph you cited is preceded by: Content model: Zero or more groups each consisting of one or more dt elements followed by one or mode dd elements. I'd say that is all that authors need. The paragraph you cited adds nothing useful to it, from an author's perspective. In fact, all the four paragraphs at the end of that section, between the examples and the note, can be considered of no importance to authors. The rest of the section is. [...] It's something that's on the cards. However, it's not a priority, at least not for me. There are several meta things I'd like to do to the spec (like have the sections be labelled for how stable they are, have the spec link to test cases, have the spec say what's implemented) before I start looking at paragraph-level annotations. Well, I can only give you my opinion :) which is that if authors have a reliable way to ignore UA-specific stuff, it will make it much easier for them to review the spec. That can only result in higher quality contributions from authors, which can only benefit the spec. The longer you wait, the later that feedback will come, by which time it may be more difficult to handle it. And yes, those other things you want to do are useful too :) and you can't do everything at the same time. I sympathise. I'm in a similar boat trying to get the WRI off the ground. But consider that it takes authors time too, to review the spec and be able to contribute to it -- I'm sure most of them don't get paid for it, so they're doing it on their own free time. A reliable method to hide UA-specific stuff would allow them to donate their free time more effectively. The same probably applies to accessibility experts and authoring tool developers, two groups that it has been said we need more feedback from. -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] Content-Type (was Style sheet loading and parsing (over HTTP))
Anne, you seem to mean to refer to Style Sheets's Content-Types only, but given some of the responses, and some other discussions about Content-Type, I take the liberty to interpret this as a more general argument against Content-Type. At 10:44 +0200 UTC, on 2007-05-22, Anne van Kesteren wrote: For compatibility with the web it seems important to simply ignore Content-Type in all modes. I'm confused about in all modes in this context. I thouht the idea was to do away with modes altogether? + With Content-Type, one can serve HTML, CSS, PHP, etc. as text/plain. Useful to provide example code. I'm sure there are more use cases where there is no single correct interpretation other than the one the author specifies. Should we really make that impossible? With content-sniffing, users need fetch images even when they cannot see them, audio even when they cannot hear it. [fetch == wait for the data transfer, pay for the traffic, and wait for the content-sniffing parser to do its dance.] + What about new types of content? It seems to me that relying in content-sniffing would mean that a new file format would have to be registered by browsers before they can do anything useful with it. With Content-Type OTOH, a browser can always be configured to do somethig useful (pass it on to an appropriate helper app) with a particular new file type. + Some of today's browser vendors may be afraid to lose market share by respecting Content-Type, but tomorrow's new browser might be able to grab market-share by doing something useful with it. Let's be very careful throwing things away too easily. + UAs can try to be clever, and content-sniff. But what about users? Over on WRI-Talk[1] we've got a discussion going about URL design[2]. The debate is whether http://domain.example/blah.xyz or http://domain.example/blah is more appropriate. The argument for using file name extensions is that they can provide a clue as to what sort of file is being pointed to, to help decide if it's worth the trouble fetching it, or *how* to fetch it. (For example, when you known in advance that alink points to a PDF, you might want to override your browser's default behaviour, end explicitly tell it to open that in a new window/tab, or save it to disk and/or open it in another application.) The argument against is that file name extensions aren't authorative (.php might return a HTMl file, a CSS file, an image, etc.) and too confusing to many users. I see value in the second argument, but have my reservations, because it would mean hiding information also from those who would find it useful. (Come to think of it, if the tender souls of users need to be saved from this evil, why do UAs still expose users to URLs?) Still, I'm considering going for this (speccing it for the WRI[3]), but adding the provision that all links provide a MIME type through the type attribute (should be easy enough anyway, for authoring tools). Obviously that too isn't authorative, and most current UAs do nothing useful with this, but it can provide a useful hint to those who care or need that, and users can make the information visible through user CSS[4]. I admit I'm not entirely sure yet just how exactly this matters to the giving up on Content-Type idea. I just have a 'gut feeling' that it does. Let's imagine we manage to get a sizeable proportion of links on web pages to contain type attributes. (I don't believe that is far-fetched. More and more web pages are generated by authoring tools, and it shouldn't be that hard for such tools to provide type attributes with links.) In that scenario I can imagine UAs warning the user when, upon fetching a resource, its Content-Type doesn't match the link's type= content. (They could do the same based upon content-sniffing, so perhaps this isn't a reat example...) [1] http://lists.webrepair.org/mailman/listinfo/wri-talk [2] http://lists.webrepair.org/pipermail/wri-talk/2007-March/11.html and on [3] http://webrepair.org/02strategy/02certification/01requirements.php [4] http://www.euronet.nl/~tekelenb/WWW/userfriendlierhyperlinks/ + I do respect Ian's years of preaching to browser vendors. I've done some of that myself, often unsuccesfully, and know how frustrating it is. I'm not convinced though that this sort of experience is evidence enough to give up on something like Content-Type. Consider that a couple of years ago the browser situation was different than it is today. WHATWG, the HTML WG and the growing care for standards-compliancy in general are evidence that unforeseen changes can make what once seamed like a lost cause into a possibility again that many are willing to invest in. True, it can be realistic to give up on a fight. But it can be equaly realistic to continue it. Environment variables tend to change, which can make the seemingly impossble possible -- unless you've cosed the door. -- Sander Tekelenburg The Web Repair Initiative: http
Re: [whatwg] Target Attribute Values
At 09:10 +0100 UTC, on 2007-05-04, Benjamin Hawkes-Lewis wrote: [...] keyboard or switch rather than mouse. (I can't work out how to tab between anchors in iCab I might be mistaken but I don't think that's currently poissible in iCab. -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] Target Attribute Values
At 01:32 -0700 UTC, on 2007-05-04, Maciej Stachowiak wrote: On Apr 29, 2007, at 9:21 AM, Sander Tekelenburg wrote: [...] FWIW, iCab[*] indicateds such cases by a change of cursor [...] Safari indicates in the status bar hover feedback when a link will open in a new window, new frame or new tab, or if it will download, if we can tell based on target setting and the user's currently depressed modifier keys. Ah, yes. I forgot. I quite like that behaviour. However, by default the entire Status Bar isn't visible in Safari, so just how many users actually benefit from this is the question ;) Unfortunately when the link action is JS we can only say that it will run a script. So it's actually better usability if the site can use target=_blank compared to using window.open(), at least in Safari. Sorry, I know very little of javascript. Are you saying it is technically impossible for a UA to know beforehand what a script will do? [...] we don't have a set of modifiers to open in the current tab in the current window. I suppose that might be useful in some cases. Definitely. iCab allows that through the contextual menu (Link-Open in This Window). It might be faster if it can also be done with modifier keys. Something along the lines of making Cmd-Opt-click to mean open in same window, no matter what. Assuming that doesn't conflict with existing behaviour, of course. In any case, for Safari especially, it will need to be self-explanatory, as that's its killer-app-aspect. A non-indicated key combo wouldn't be approriate. But an option in the contextial menu, indicating the alternative key combo, probably would be. -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] style='' on every element
At 12:53 +0300 UTC, on 2007-05-04, Henri Sivonen wrote: [...] Considering all the above, here's my concrete proposal for a solution: 1) Make style='' a global attribute. For the purposes of document conformance, make it conforming on all documents regardless how they came to being. 2) Include an informative paragraph about how media-dependent use of style='' is bad. 3) I make the conformance checker emit a warning (at most one per document) that paraphrases the informative paragraph when the conformance checker sees a style='' attribute. 4) I make the WYSIWYG signature suppress the warning. 5) font is either made non-conforming or made a strictly inline element with the attribute color (to avoid span style='color: ...' cruft). I think I would agree with 1 through 3 (Michel Fortin's objects to 3, but the rationale he gives seems to only apply to 4. So I don't understand the objection to 3. But perhaps I misunderstood.) The at most one per document restriction under 3 I'm not entirely sure about though. I understand it's counter productive to bug users about issues more often than strictly necessary. But for authors who rely on conformance checkers to find their mistakes so they can fix them, it would be quite unuser-friendly to have this warning not point out every instance of that particular mistake. So ideal behaviour would probably be a single warning, listing all instances. But is that something that can/should be specced? I don't know. Btw, would this be a first for defining something conforming but requiring conformance checkers to emit a warning? Or are there other instances already? I'm not so sure about 4. Several thoughts: - Is somone actually asking for this, or is it just assumed that some party wants this? (At http://krijnhoetmer.nl/irc-logs/whatwg/20070503I see the claim that WYSIWYG editor authors want document conformance *and* font/inline style, but I don't recall having seen that actually being requested.) - Why is a conformance checker config option needed to be in the HTML spec? Wouldn't it be better to let people configure conformance checkers themselves? (Compare W3C's CSS 'validator'.) - What is WYSIWYG, and why only WYSIWYG? In other words, if we should define an opt-out switch for conformance warnings, wouldn't it be cleaner if it were just that (conformance level=errors|warnings|none), instead of tying it to 'WYSIWYG' editors specifically? It could be more general, with an optional list of specific warnings to suppress. - How do 'WYSIWYG' editor and host applications communicate? I mean, in the real world, how does an embedded editor actually generate a WYSIWYG signature in the head? - As Michel Fortin said: what if 'WYSIWYG' output is changed through some non-WYSIWYG mechanism, or vice versa? Should the WYSIWYG sig be removed by the non-WYSIWYG editor (be it a person or a tool)? If so, what makes us think that person or tool will actually have access to that WYSIWYG sig? And in the other direction, should the WYSIWYG sig be inserted when changing content that doesn't yet contain it? In fact: should the WYSIWYG sig be produced by any WYSIWYG tool, or only WYSIWYG tools that want to suppress this particular conformance cheker warning? Or to put it differently, 4 just seems too complicated to me ;) As to 5, I don't understand what the use is to allow font color. The only argument I've heard is that apparently today's HTML-PDF converters ignore CSS. (Well, the affordable ones, that is :)) -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] font
At 11:01 +1000 UTC, on 2007-05-02, Adrian Sutton wrote: On 2/5/07 1:28 AM, Sander Tekelenburg [EMAIL PROTECTED] wrote: [...] can you explain exactly how span is much more difficult to work with, and for whom? Quite a number of the cheap HTML to PDF conversion processes don't support CSS. Additionally, syndicated HTML (via Atom, RSS etc) tends to have inline CSS removed because of cross site scripting vulnerabilities (you can embed JavaScript in CSS and at least IE will execute it). OK. Real world issues. But that doesn't mean that the HTML spec is the place to fix those. Looks more like an opportunity for beter PDF generators to grab market share and for IE to fix security bugs. [...] Some people do restrict the editor to just applying predefined CSS classes and as a result they get a very consistent, easy to maintain site. Most however, prefer having the flexibility of a font menu so they can apply the specific font they won't precisely when they want it. OK. Too bad. Still, I don't see why this would warrant making font conforming. [...] People want the editor to look and work like Microsoft Word and Word has a font menu. Right. Given that that is what they're used to that's understandable. However used to implies that the same people could work with a more semantic editor, if they'd be used to that. People get born every day without yet being used to Word. -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] font (was Support Existing Content)
At 12:48 +1000 UTC, on 2007-05-01, Adrian Sutton wrote: [...] The only debate about what a WYSIWYG editor is on the web is between a very strict interpretation (it must look precisely like what you get) and the What You See Is What You Mean editors. That's one, yes. But also plenty of people don't even distinguish between the editor embedded within a publishing tool, and the publishing tool as a whole. So as it is phrased now in WebApps 1.0, I wouldn't be surprised if it will be taken to mean that any authoring tool is allowed to produce font. Anyway, I understand that there can be exceptional conditions (not that I'm convinced that this is one) that require that something that we don't really want is allowed in HTML after all. But I'm worried about setting the precedence that the source of a document can be decisive in whether or not it is conforming. Next could be to allow authors to whom CSS is too hard to abuse blockquote and table, or to consider a colour property conforming if the author isn't american. So what I'm saying is that, *if* font must be allowed, let's just plain allow it -- not only allow some authors to use it. I'm also worried about how allowing font would affect end users. What guarantee is there for end users that when they set their default and minimum font sizes, be it through User CSS or a GUI, that that one single setting will affect both font and CSS font rules? The term WYSIWYG really shouldn't be a concern for any reasonable person reading the spec. FWIW, my impression is that it is and will be. That's why at http://webrepair.org/ we avoid the term and instead say inline editor. Embedded editor might work too. Anyway, is the current phrasing intended to mean that an editor that 'is' not WYSIYWG, but *is* an editor, is not allowed to produce font? I've been working in this area for around 6 years now and I've never met anyone even semi-technical that didn't immediately understand the term WYSIWYG and know what it meant in terms of HTML editors. I'm surprised. My experience is that people take WYSIWYG in the original DTP meaning. Slapping that terminology onto the context of the Web confirms their misguided idea that that meaning of WYSIWYG applies to the Web. We cannot force authors of such tools to avoid that term, but I believe it is unwise to use the term in the spec. If you outlaw the font tag, you'll just get span style=font-family: ... instead which has no more semantic benefit and is far more difficult to work with. The current phrasing doesn't restrict this to span. It allows WYSIWYG editors to produce pfont size=7blah/font/p where h1blah/h1 is appropriate. As to span, can you explain exactly how span is much more difficult to work with, and for whom? That said, in general I recommend configuring the editor so it doesn't have a font menu and use predefined CSS styles instead Agreed. , but few people ever take that advice. Which people are you referring to? Authoring tool authors? Or the users of EditLive? -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] font
At 12:47 -0500 UTC, on 2007-05-01, Jon Barnett wrote: [...] the only attribute specifically allowed on font is the style attribute. Whoops. Somehow I overlooked that. My bad. But given that, I *really* don't see the point of font anymore. I've searched the archive at http://lists.whatwg.org/pipermail/whatwg-whatwg.org/ but can't find any discussion leading to http://www.whatwg.org/specs/web-apps/current-work/multipage/section-presentational.html#style0. Maybe Ian can explain where this entry in the spec comes from; what the rationale behind it is? [...] Hopefully before editors start putting an HTML5 DOCTYPE on HTML files, they'll stop using font in favor of something else. Until then, they can happily put HTML 4.01 Transition (not even Strict!) on their documents that include font From what I've seen typically these editors are used to edit fragments only. They don't generate doctype declarations or any part of the head. They are only used for (parts of) the body. Btw, that seems to show another aspect of the problem with rather undefined WYSIWYG editors I mentioned earlier: I don't believe it is common that an inline/embedded/whatever editor is in the position to generate a WYSIWYG signature through a meta element in the head. Typically that area of the document is controllled by the host application itself, not by the editor embedded in it. So for authoring tools to meet this requirement, both the host environments (CMSs and such) and the editors embedded in them would need to implement a common communication method. (Which would be very useful, for example to make it easier to embed conformance checkers. But that's another story.) -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] font (was Support Existing Content)
At 15:01 -0700 UTC, on 2007-04-30, Maciej Stachowiak wrote: [...] Note that although the WHATWG spec requires UAs to support FONT, it makes it non-conformant for documents except those created by a WYSIWYG editor. And even that aspect is in dispute. Yeah, I meant to ask about http://www.whatwg.org/specs/web-apps/current-work/multipage/section-presentational.html#the-font. What's the argument for making font conforming? I can't think of a good reason. What's even more weird is the idea to consider content non-/conforming depending on how it was authored. I can't believe the implications of that were given serious thought. (Not to mention specifically granting wannabe 'WYSIWYG' editors special status. WYSIWYG has nothing to do with the Web -- people wildly disagree over what WYSIWYG means in the context of the Web. So even if there is some sound argument behind allowing font, tying it to some undefined tool is useless -- at best everyone authoring font will bother to claim to be a WYSIWG editor.) -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] Target Attribute Values
At 00:36 +1200 UTC, on 2007-04-30, Matthew Paul Thomas wrote: [...] If _blank is allowed, I would prefer the specification to discourage authors from using _blank when another solution is practical (e.g. using a details element in the original page) Yes, having the spec list common (ab)use cases and pointing authors to better options for those would be good. , and encourage UAs to indicate when a link will open in a different top-level browsing context (e.g. by double-underlining instead of single-underlining). FWIW, iCab[*] indicateds such cases by a change of cursor upon hovering over the link. (You get the same cursor when you Cmd-click or Cmd-Shift-click the link, to load it in a new window on purpose.) This way you can keep such UA functionaility in the chrome -- no need to mess with the content's presentation itself. [*] http://icab.de/ -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] Alt text authoring Re: Conformance for Mail clients
At 07:45 +0200 UTC, on 2007-04-22, Charles McCathieNevile wrote: On Thu, 19 Apr 2007 15:43:14 +0200, Thomas Broyer [EMAIL PROTECTED] wrote: 2007/4/19, Matthew Paul Thomas: Thunderbird allows you to set 'alt' ... When you drag/drop an image into a message, the default is alt=. Setting a default of alt= is bad behaviour Indeed. As is careless reuse of previously entered data. See ATAG checkpoint 3.4: http://www.w3.org/TR/ATAG10/#check-no-default-alt [...] The application should simply leave out the alt attribute. This makes it trivially easy to build a repair application where one is required or desired, and has no practical drawback if the error is left in (given the state of HTML email standardisation...). Given that given that might be the best approach, yes. -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] IE/Win treats backslashes in path as forward slashes
At 3:13 PM +0100 UTC, on 4/11/07, Gervase Markham wrote: Geoffrey Sneddon wrote: Looking through the spec again, there is nothing about backslashes in URI's path being treated as a forward slash, behaviour needed for compatibility for quite a few websites. I would be rather surprised if that were true Be surpirsed: http://santek.no-ip.org/~st/tests/backslash/ I've no idea how many sites rely on this, but given that Safari copied this behaviour apparently Apple found the problem big enough to bother. -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] Default (informal) Style Sheet
At 09:54 +0200 UTC, on 2007-04-02, Anne van Kesteren wrote: On Mon, 02 Apr 2007 09:59:50 +0200, Sander Tekelenburg [EMAIL PROTECTED] wrote: [...] Surely we're not trying to ensure that a Web page is presented the same in every browsing environment? What would be the use of that? That's what people expect from us (browser vendors). Which people? And just because they expect it from you, does that mean you (browser vendors), let alone 'all of us', should give them that? So yes, that's what we're trying to ensure. Leaving aside for a moment whether it would be a good idea at all, I don't see how UA authors *can* ensure this. For example, I don't see how a site can look the same on a 21 desktop system, and a 3 portable one *and still be usable*. Add to that the possibility of a User Style Sheet, which means authors *cannot* be ensured that something will be presented this way or that. If in spite of that reality the spec say that x must be presented y, then we'd be telling Web authors they can rely on something they in reality cannot rely on. In practice, this can only result in yet more sites that are only usable to users willing to hand control over to the site's author -- even more sites that require a windows size of x, font-size of y, etc. The more specific the HTML spec says how x must be presented, the more trouble users will have configuring their UA to present content the way that is comfortable to *them*. Is HTML5 to accomodate authors, or users? [...] Not all authors will use a 'CSS zapper' (whatever it is). If that's a question, I linked to what it is in my first message in this thread: http://webrepair.org/02strategy/02certification/01requirements.php#req26 They will still expect the same results across user agents. Why should HTML5 fulfill unreasonable expectations from Web authors? -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] Default (informal) Style Sheet
At 16:20 +0200 UTC, on 2007-04-02, Thomas Broyer wrote: 2007/4/2, Asbjørn Ulsberg: [...] Should the HTML or CSS specification then encourage HTML and CSS authors to use such a zapper to get expected visual results across browsers? Why not, but such a zapper should then be given in the spec(s). Agreed. -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] Default (informal) Style Sheet
At 12:52 +0200 UTC, on 2007-04-02, Asbjørn Ulsberg wrote: On Mon, 02 Apr 2007 09:59:50 +0200, Sander Tekelenburg [EMAIL PROTECTED] wrote: [display: block and inline] Defining preseantation up to *that* level is no problem IMO. Great! Then let's. The current (HTML 4) spec already does so, and in fact this is no more than a translation of HTML's distinction between block and inline level elements to CSS terminology. That translation already leads to a plethora of different results, CSS-wise. Is the whitespace around a p margin or padding? What is the default style of li elements? Do they have outside or inside alignment? Padding or margin or both? What is their line-height? I can't follow your logic. Those different results do not stem from a translation of block and inline level elements to CSS terminology [...] I didn't get the impression from the OP though that the aim was to restrict specifying of presentational defaults to this level. That's up to us to dicsuss. What level of presentation default we choose to specify is not yet specified. ;-) Maybe it would be good then if you'd start by suggesting some specific default styles. That would help us understand exactly what we're talking about. FWIW, my current view is that HTML should not define default margins, paddings, fonts/sizes, colours, etc. Having some defaults is either way better than having none, imho. Why? (The OP said informal and within limits, but didn't define that.) I didn't define it for a reason. I thought so :) I'm inviting you to define those ;) It would help make more clear what exactly we're discussing. As I asked before: how does an author provided 'CSS zapper' not do that? Should the HTML or CSS specification then encourage HTML and CSS authors to use such a zapper to get expected visual results across browsers? That would get my vote, yes. (For CSS authors. HTML has nothing to do with presentation.) How in fact does requiring default presentations remove the need for authors to provide 'CSS zappers'? You can't require anything with informal (non-normative) language. It's just the normative part of the specification that can be required and enforced. I proposed it as informal fragments for a reason, and even if the browser vendors aren't required to implement it Even if default presentations would be shoulds, the signal to Web authors would still be you can rely on your site to look like x. -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] Default (informal) Style Sheet
At 03:18 -0400 UTC, on 2007-04-02, Mike Schinkel wrote: Sander Tekelenburg wrote: [...] What exactly, in the context of presentation, would be good about consistency *across* UAs? See Jakob's Law of Internet User Experience http://www.useit.com/alertbox/2723.html I fail to see the relevance. I don't see Nielsen argue for margins, colours or fonts/sizes to be the same in every browser. (Note that I specifically said *across* UAs.) If anything, Nielsen there argues for the same type of thing I argued for at http://www.euronet.nl/~tekelenb/WWW/LINK/. -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] Default (informal) Style Sheet
[Mike, you are making the communication more difficult by changing the Subject header without a good reason. Doing so fragments the discussion, makes it harder for people to keep track of what is said in relation to what. I'm changing the Subject back to what it was.] At 00:13 -0400 UTC, on 2007-04-02, Mike Schinkel wrote: Sander Tekelenburg wrote: [...] [http://www.whatwg.org/specs/web-apps/current-work/#rendering] What instead this should say is something like When taken to a fragment identifier, UAs must clearly indicate the referenced point in the content to the user. Because that *clarity* is what counts, not *how* that clarity is provided. For example, a UA could indicate the target by hiliting it for a couple of seconds, as iCab does. To me, as a user, that's a way more useful and elegant solution. That's not a great solution because of color blindness Agreed. That emphasises my point, doesn't it? No particular implementation should be mandated by the HTML spec, because it won't fit every conceivable browsing environment. [...] Similarly, it would make sense for the spec to say that by default, occurences of title attributes must be clearly indicated to the user, and occurences of LINK elements must be clearly indicated to the user. But not *how* they should be indicated. Though I get your point somewhat, defining how is helpful because it increases consistency. What exactly, in the context of presentation, would be good about consistency *across* UAs? Maybe a How (but only where applicable) is the better solution. I've argued before for naming examples of possible implementations in the spec. That would help both UA authors and Web publishers better understand what the spec's intention is. But that's something entirely different than *requiring* a specific implementation. [...] There is a necessary balance that needs to be struck between innovation and consistency. If innovation always won, there would be no need for any standards bodies, but then we'd see no progress, only chaos. Swinging the pendulum too far in either direction is dangerous. That was my point exactly. I raised specific objections for taking the spec so far as to specify default presentations, and asked what would be gained by ignoring them. -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] Default (informal) Style Sheet
At 19:30 +0200 UTC, on 2007-04-01, Anne van Kesteren wrote:
On Sun, 01 Apr 2007 20:16:12 +0200, Sander Tekelenburg [EMAIL PROTECTED]
wrote:
Who are we (as spec definers) to decide that x is the only correct
behaviour or presentation? And why should we want to stifle innovation
by requiring some specific presentation?
Defining default rendering for certain constructs such as that the body
element has a default margin of 8px (iirc) is important for
interoperability reasons
I'm not sure I understand. Exactly what interoperability are you referring to
here? Surely we're not trying to ensure that a Web page is presented the same
in every browsing environment? What would be the use of that?
and for new UAs trying to enter the market (saves
them reverse engineering other UAs).
Hm... That might indeed be a problem looking for a solution. But I'm not at
all convinced that requiring body {margin:8px} is the proper solution. Even
if it were the ony possible solution, I'm not convinced the benefits outweigh
the objections I raised.
A lot of web pages rely on default
rendering of elements. For instance, that an element such as p has a
default style of display:block as opposed to display:none.
Defining preseantation up to *that* level is no problem IMO. The current
(HTML 4) spec already does so, and in fact this is no more than a translation
of HTML's distinction between block and inline level elements to CSS
terminology.
I didn't get the impression from the OP though that the aim was to restrict
specifying of presentational defaults to this level. (The OP said informal
and within limits, but didn't define that.)
It is very important that UAs falling within the same conformance class
agree on these basic principles so authoring against those UAs becomes
more predictable
As I asked before: how does an author provided 'CSS zapper' not do that? How
in fact does requiring default presentations remove the need for authors to
provide 'CSS zappers'?
--
Sander Tekelenburg
The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] Default (informal) Style Sheet
At 03:38 +0200 UTC, on 2007-04-01, Asbjørn Ulsberg wrote: [...] While I'm a strong believer of separation between structure (HTML), presentation (CSS) and functionality (JavaScript), I think it could be useful for the HTML specification to -- within limits -- define how each and every element's default CSS properties and values should be like. This could improve interoperability in the presentation layer, since no author starts with a blank canvas when composing his style sheet. FWIW, the WRI requires AWPSs[*] that generate CSS to include a 'CSS zapper': http://webrepair.org/02strategy/02certification/01requirements.php#req26. What would your proposal achieve that an author provided 'CSS zapper' does not? I can think of a few downsides: - The ideal presentation of something cannot be defined universally. What works well in one browsing environment doesn't necessarily work well in another. - It takes ages to define and implement a spec. Leaving UAs no room to in the mean time improve their built-in Style Sheets will slow down development. - Built-in Style Sheets leave UAs room to distinguish themselves from their competitors and can thus be an incentive to innovate, which can in turn make all UAs grow towards more maturity. - The user may well have changed the built-in Style Sheet to some other default, so authors won't be able to rely on a certain default presentation anyway. Why should these downsides be acceptable? Leaving aside whether the objective is desirable, I doubt this could even ever result in the objective. Even if HTML would spec a default presentation for everything, then still authors can not rely on every browser actually implementing that. So they'd still need to use a 'CSS zapper'. Frankly, I can't even imagine that we'd be able to agree on a default presentation for everything. So I suspect that at best this could result in an incomplete list of default styles, which would mean authors would have to provide a 'CSS zapper'. The fact that you already say within limits (what limits exactly?) and informal (in the Subject) mean suggests you are aware of these issues. At 12:28 +1000 UTC, on 2007-04-01, Lachlan Hunt wrote: [...] Yes, that will be defined in due course. http://www.whatwg.org/specs/web-apps/current-work/#rendering That saying when scrolling a page to a fragment identifier, align the top of the viewport with the target element's top border edge, seems to emphasize my argument. This is a silly requirement. When the anchor is near the end of the document, it would result in empty space below the document (what should happen with bottom fixed positioned content?). I doubt users and Web publishers would appreciate that and that UA authors would implement that. What instead this should say is something like When taken to a fragment identifier, UAs must clearly indicate the referenced point in the content to the user. Because that *clarity* is what counts, not *how* that clarity is provided. For example, a UA could indicate the target by hiliting it for a couple of seconds, as iCab does. To me, as a user, that's a way more useful and elegant solution. Similarly, it would make sense for the spec to say that by default, occurences of title attributes must be clearly indicated to the user, and occurences of LINK elements must be clearly indicated to the user. But not *how* they should be indicated. Who are we (as spec definers) to decide that x is the only correct behaviour or presentation? And why should we want to stifle innovation by requiring some specific presentation? [*] Automated Web Publishing Systems. -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] video element feedback
At 22:17 + UTC, on 2007-03-25, Kornel Lesinski wrote: On Sun, 25 Mar 2007 20:28:38 -, Elliotte Harold [EMAIL PROTECTED] wrote: [...]allowing authors the ability to override the browsers controls [...] Seems to me the user shoudl be in control here [...] [...] Authors use unskippable ads in Flash videos already. If video won't let them do the same, most likely they simply won't use video. Lack of control hasn't stopped authors from using CSS, nor has it made them switch to PDF. By leaving the user in control a UA should per definition be compliant. Allowing authors to make suggestions is good. Removing control from the user is not. (An individual UA could still choose to favour authors over users, just like a UA can ignore anything else in the spec -- users can vote with their wallet. But specifically requiring UAs to give authors control on the WWW would be dead wrong.) -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] video element feedback
[My apologies for initially responding off-list. That was unintentional. I'm posting an updated version.] At 20:04 + UTC, on 2007-03-21, Martin Atkins wrote: Sander Tekelenburg wrote: [...] URL:http://domain.example/movie.ogg#21:08, to mean fetch the movie and start playing it at 21 minutes 8 seconds into the movie. [...] When using this with HTML we don't link to #line50, or #paragraph3, or #section9, we link to an anchor in the document itself. We do this to avoid tying the link to a specific representation of the resource, and to allow the document to change to a certain extent without breaking the links. FWIW, RFC 3986, under 3.5, seems to me to specifically mentions this [...] Although this separate handling is often perceived to be a loss of information, particularly for accurate redirection of references as resources move over time, it also serves to prevent information providers from denying reference authors the right to refer to information within a resource selectively. Indirect referencing also provides additional flexibility and extensibility to systems that use URIs, as new media types are easier to define and deploy than new schemes of identification. It seems to me that what I'm proposing is very much in the spirit of this. I don't know of a video container format that allows named anchors to be specified, though. QuickTime let's authors define points in a .mov container as chapters, which, in the cotext of the Web, could function as named anchors I'd think. I believe this is in fact already possible today with QT authored movies. But I didn't get the impression that this authoring aspect matters. In fact, the essence of my suggestion is exactly that this would be an opportunity to allow for fragment identifiers without any need for authors to do any extra work. If the spec requires UAs to be able to return the movie's duration and current position, etc. (which I got the impression is the intention of both Opera and Apple's proposals), to for instance allow, through javascript, playing from a certain point, then I don't see why it would not be possible to trigger the same event through a fragment identifier. I don't see how this would require anything from the author. The interpretation of fragment identifiers on video is a bit out of scope for an HTML specification regardless of whether it's specified as time or a bookmark. If someone invents a video format that allows named anchors, they can write in their own specification how fragment identifiers are to be interpreted. It's none of HTML's business. Quoting that last bit of RFC 3986, section 3.5 again: [...] Indirect referencing also provides additional flexibility and extensibility to systems that use URIs, as new media types are easier to define and deploy than new schemes of identification. The discussion here of a video element, for native playback of even a specific codec, seems to come quite close to that. (That aside, a lot of what is being defined on this list is javascript, not HTML. The popular term HTML5 is misguiding. The offical name Web Apps 1.0 is more descriptive.) -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] video element feedback
At 19:46 + UTC, on 2007-03-22, Nicholas Shanks wrote: On 22 Mar 2007, at 19:23, Sander Tekelenburg wrote: [...] We're not talking about IDs, just fragment identifiers. My point was that with video, you could use fragment identifiers *without* the need for the author to provide IDs. I see your point, but i would like for fragment identifiers within a video to be equal to fragment IDs in text fallback content. I completely agree that that would be ideal. But I consider it an argument to try to find a solution for that, or if that's not possible, live with that. I don't see it as an argument to give up on such a useful feature for users who do not need/choose to fetch non-video fallback content. (Note that a mechanism to allow authors to define anchors in videos is not a solution, because it's then still the author who is in control. What I'm suggesting is about giving the user control.) [...] the client doing the request should be smart enough to know to escape the colon Wikipedia section IDs have lots of escaping, but it's all done by the wiki server, not the UA. I don't know if this is because UAs can't be trusted to get it right or not. I'm getting the impression from RFC 3986 that it is up to the app that sends the request to ensure the URL is properly percent-encode (meaning special characters are escaped). For instance Section 2.2: [...] URI producing applications should percent-encode data octets that correspond to characters in the reserved set [...]. And section 2.4: [...] Under normal circumstances, the only time when octets within a URI are percent-encoded is during the process of producing the URI from its component parts. This is when an implementation determines which of the reserved characters are to be used as subcomponent delimiters and which can be safely used as data. Once produced, a URI is always in its percent-encoded form [...] -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] video element feedback
At 07:53 +1100 UTC, on 2007-03-23, Silvia Pfeiffer wrote: [...] About 8 years ago, we had the idea of using fragment offsets to start playing from offsets of media files. However, in discussions with the URI standardisation team at W3C it turned out that fragment offsets are only being seen by the UA that sends them, so they will never reach the web server. Right. See RFC 3986, section 3.5: [...] the fragment identifier is not used in the scheme-specific processing of a URI; instead, the fragment identifier is separated from the rest of the URI prior to a dereference, and thus the identifying information within the fragment itself is dereferenced solely by the user agent, regardless of the URI scheme. [...] This makes it impossible to use them for play from this offset since obviously the offsetting should be done by the server While that might be useful, it's not at all obvious to me that it is a *requirement*. What is so wrong with fetching the entire file, and start playing it at the point referenced by the fragment identifier? That's how fragment identifiers work for textual resources (and they fetch the usual truckload of images along with the HTML file). Sure, with 'big' files and 'slow' connections, that would mean having to wait longer. But big and slow are relative values. And when you want to watch something only from point x on, even if that means having to wait, that's still much better than having to first watch all of the video before that point. At least while you're waiting, you can still do something useful ;) [...] The only solution was to use the query ? identifier for defining offsets. Unless I'm misunderstanding something, that makes things server-dependant. I recognise that the benefit of this approach is being able to only fetch the data you want, but it doesn't offer the user the benefit of easily being able to refer to a specific point in any movie (in a video element). -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] video element feedback
At 09:25 + UTC, on 2007-03-20, Ian Hickson wrote: [...] ON NATIVE UI: [...] I completely agree that on the long term this is something we need to offer. However, we musn't bite off more than we can chew. There are several sets of use cases, some of which require browser-provided UI, and some of which need just video playback under the control of the author. I thought the idea of the Web was that the user is always in control (because the author cannot know the user's browsing environment). Why would authors ever have to be in control? [...] If JS is turned off, applications won't work. :-) Just like when you turn JS off and try to use Google Calendar, or turn off Flash and try to use YouTube. If video is to be a first-class Netizen, it'd better not be javascript-dependant. Currently Flash and QT plug-ins handle embedded video just fine without JS (unless when misguided authors purposely made it javascript-dependant). If video is specced to be javascript-dependant, you make it too difficult for both users and authors. I'd have to vote against that. Simply video src=URL should suffice. (I'm all for allowing more sophisicated things through javascript, just not for *dependancy*.) Something else concerning first-class Netizenry: I'd like to see the spec to require UAs support implicit anchors, so that one can link to a specific startpoint: URL:http://domain.example/movie.ogg#21:08, to mean fetch the movie and start playing it at 21 minutes 8 seconds into the movie. (Or better yet, if this can be achieved reliably, don't fetch the entire movie, but only from 21:08 on.) Without this/currently, video consumption just costs too much time. It's usually much more practical to deal with text, because users can imediately go to the part they're interested in. With video (and audio) you are forced to watch the whole thing to find out if there is anything interesting. It seems to me that's one of the main reasons video is very much a second-class Netizen today. Note that such an implicit anchor mechanism would in a sense make video even better than text, because this wouldn't require authors to bother to provide anchors. The less work for authors, the better the chance at first-class Netizenry. (Btw, the same mechanism could be used to, through cookies, or even through a cache-like local mechanism (and thus again not author-dependant), allow UAs to provide a bookmarkish function for a start playing from where I left last time feature.) [...] I agree that video needs a standard UI (in v2, at least). It needs it right from the start, in v1.0. Without it, it would be like a browser without its own back button, relying on authors to provide such functionality. IMO this is no different than CSS being icing on the cake. It's nice to allow authors to suggest UI-styling and even add functionaility, but it's a mistake to make basic functinality (start, stop, pause, (fast)forward, etc.) author-dependant. -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] video element feedback
At 23:02 +0100 UTC, on 2007-03-20, Håkon Wium Lie wrote: Also sprach Martin Atkins: If video is going to be considered a first-class citizen, I argue that this needs to be possible for video as well: video src=pretty.ogg.../video Right. I think I agree with you. Perhaps we can encourage implementors to add a simplistic UI in case none has been specified? Agreed. On the right-click menu or somewhere where it doesn't take up space? Implementation should be left up to the browser author, but it would probably be useful if the spec lists some suggestions. Both to help browser authors understand what the spec means, and to help content authors realise that how their favourite browser behaves may not be how some other browser behaves. I agree it would probably be important to state that the UI must not take up extra space. (An author-provided UI however should be allowed to take up author-defined space.) Btw, please let's not have the spec say right-click, when contextual menu is meant. How to bring up a contextual menu is entirely environment-dependant: my mouse has no right button at all, but I use contextual menus all the time. Also, my preferred OS offers a native Action button/menu (typically in a toolbar) to contextually provide access to actions. Another possible UI would be straight from the keyboard, as is already the case with the QT plug-in for example. The mouse hover-based UI of QT and VLC that has been mentioned is probably another good example (although requiring users to hover over the video will mean many won't ever discover this functonality, just like the contextual menu -- I imagine this is what Apple's Action button aims to solve). -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] Attribute proposal: video autostart
At 02:28 +0100 UTC, on 2007-03-19, Simon Pieters wrote: [...] Therefore (to ease authoring and thus help adoption) I would like to propose a new boolean attribute for video: autoplay=autoplay. It's presence would be equivalent to invocing play() on the video ASAP. If it's a boolean, why not autoplay=true? Or if you want to make it easy for less-techy authors, just a valueless autoplay atribute. (At the very least, this sort of thing should be consistent throughout the spec. HTML 4 and CSS 2 are inconsistent in this area, which makes it too easy for authors to make mistakes.) -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] require img dimensions to be correct?
At 15:28 -0800 UTC, on 2007-03-17, Andrew Fedoniouk wrote: [...] So the main motivation is to avoid jumpy rendering, correct? Correct. In principle style sheet downloading is also asynchronous process. And CSS can do many things that may cause jumps. So if we will require image to have known dimensions up front then this means that CSS has to be loaded before any initial rendering. I mean that img width=... height=... is only one piece of the puzzle. Fair point. http://webrepair.org/02strategy/02certification/01requirements.php#req24 may need to be reconsidered. (All those requirements are just an initial take anyway. Feedback is required before it can become a stable document.) I think that in most cases will be better if we could package complex pages into zip envelopes and deliver them in the whole. Maybe. But then you'd need sophisticated content-negotiation, or otherwise you'd force data to be downloaded by UAs that can't or won't handle it. (I don't mean the zip file itself, but its content.) -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] audio vs. video
At 20:12 -0800 UTC, on 2007-03-17, Benjamin West wrote: [...] * Should users be given a control to manipulate embedded audio? Obviously, yes. A UA that doesn't would be even worse than one that doesn't provide protection from 'pop-ups'. * If using Audio(), who's responsibility is it to provide that control/user interface? UA? Authors? The UA. Letting each and every content provider decide on the UI for their content just creates usablity hell for end users. Content providers will likely want to provide their own UI, if only for 'branding'. So, for adoption sake, it might be wise to allow this, but UAs would have to allows users to override that in favour of the UA's built-in UI. (See also http://www.euronet.nl/~tekelenb/WWW/LINK/ for the general argument.) -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] Clarify how to indicate document hierarchy
At 19:52 + UTC, on 2007-03-15, Spartanicus wrote: [...] [...] I felt obliged to write something on the subject myself. Part 1 is about heading usage: http://codewallop.110mb.com/goodpractice/headingology.htm NIce. I've linked to it from http://webrepair.org/02strategy/02certification/01requirements.php#req9 -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] article: do we really need this?
At 08:22 + UTC, on 2007-03-06, Benjamin Hawkes-Lewis wrote: Sander Tekelenburg wrote: [...] [http://webrepair.org/02strategy/02certification/01requirements.php#req20] Well, that makes some sense for block elements, but less for inline elements. Agreed. [...] it would be good to think of a how to systematize resilient identifiers so that content can be added and deleted without a) running out of identifiers or b) fragments being misindentified. Good point. But for an automated web publishing system it shouldn't be that hard to ensure generating new IDs -- not reusing old ones. http://webrepair.org/02strategy/02certification/01requirements.php#req20 updated to accordingly. Btw, browser authors could contribute to adoption of such a practice by making it easy for users to find such IDs. One implementation might be to, through the contextual menu, place a link with fragment identifier to that specific section on the clipboard. FWIW, HyperTextuality extension does this Excelent! :) -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] require img dimensions to be correct?
At 19:58 + UTC, on 2007-03-03, Ian Hickson wrote: On Sat, 3 Mar 2007, Elliotte Harold wrote: [...] I'm +1 on allowing percentages. That seems like a useful feature to me. Allowing percentages would be entirely presentational and thus have no place in HTML. The question isn't whether or not you should have the ability to scale images; it's clear that this is desirable. The question is whether it makes sense to put this in HTML as opposed to CSS. Why would HTML be the place to put this? If we put this in HTML, how can we still drop font, table border, td width, etc? We struggled with this for the WRI requirements[*]. We seem to be settling on requiring a width and height to be specified in HTML, because as nice as CSS is, Web pages must not be CSS-dependant. Even if the author means to provide CSS, it might not be available (network/server error; saving and local viewing of the HTML file; User CSS overrides) (A followup requirement would probably have to be that when CSS is available, and specifies IMG size in px, it must be the same as the size specified in the HTML.) The only other sensible option would be to completely disallow width and height in HTML. But that will result in 'jumpy rendering' because browsers can't allocate the proper rendering space until the image's dimensions are known. [*] http://webrepair.org/02strategy/02certification/01requirements.php Btw, this is our initial take. We very much welcome community feedback. -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] Authoring Re: several messages about HTML5
At 16:37 -0500 UTC, on 2007-02-25, Adrian Sutton wrote: [...] Dave Ragget wrote: Some short cuts are common place, whilst others seem to be very specific to the particular tool. Another challenge for browser based editors is that the browsers define their own short cuts and the editor needs to be a good citizen. The problem is that browsers vary considerably in what short cuts they provide. Opera in particular provides a great deal. This risks interfering with the conventional short cuts for editors, and something I will have to look into very carefully. I feel your pain with having to avoid browser defined shortcuts. The advantage of being a Java applet is that when we have focus our shortcuts override the browsers - except on Mac. We have no end of complaints from Mac users that the keyboard shortcuts use control instead of command, but it's the only way we can realistically avoid the browser's shortcuts and still leverage off of the users existing knowledge of shortcuts. For a JavaScript editor you may need to use this different modifier trick on all platforms. Users definitely love their shortcuts though. Might this not be solvable by having browsers let users use external editors? (I have this vague notion that OmniWeb offers this, but I may be wrong.) The big 'trick' that would be involved would be to have the editor automatically pipe everything back to the browser. I don't know about Windows, but on a unix system that concept isn't alien. Mac OS X would also have AppleEvents available for this. (I don't know enough about other OSs.) It's a more general problem anyway. Not just for inline editors, but for any text area. The editing possibilities are always much poorer than what dedicated editors offer, and people may be used to. -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] Authoring Re: several messages about HTML5
At 17:33 -0500 UTC, on 2007-02-25, Adrian Sutton wrote: [...] I don't think we should be too afraid to offer an authoring tool that works a little different from what people are used to [...] Well, you can try and see what users think of it. For better or worse, forcing people to learn is not a popular option for users or integrators of editors. Very true. Such a tool should therefore do its magic as much in the background as possible. (And like you I see hurdles that will need to be taken.) Still, reality is that there is more and more legislation around the world that requires at least certain parties to ensure their sites be accesible, and thus does force people to learn to do things more right. So even if a semantic editor would require its users to learn some things, it would still in fact make their life easier than if they need to comply with such legislation using an unfit wannabe-WYSIWYG tool. That group (and a few others) seems a likely potential early adopter. Even if it stays there it would be doing good, but once one or two such groups get used to using such an editor, it will probably 'trickle down' to others. (Btw, I realise there may seem to be some naivity on my part, but that's very much on purpose ;) Cynicism just stops one from even trying.) [...] If you can make it semantic and pretty, you've got a winner. Agreed. -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] Authoring Re: several messages about HTML5
At 17:15 -0500 UTC, on 2007-02-21, Adrian Sutton wrote: [...] When people get into writing they want to focus purely on what they are writing and they don't want to have to think for a second about how the authoring tool they are using wants them to work. If you want the tool to succeed you will need to solve the keyboard shortcut problems - they are vital, Agreed. you will also need to make sure that whatever interface you come up with to try and get users to create semantic mark up doesn't require them to think about it. Well, not *think* as in make it hard, no :) It needs to be as 'natural' as possible[*]. Still, part of what people consider natural is what they're used to. I don't think we should be too afraid to offer an authoring tool that works a little different from what people are used to (yet no more than necessary). People used to not be used to cars and telephones, but they did get used to them and find them very natural now. [*] ATAG 1.0 makes some good points about this: don't bother the user unnecessarily. But it doesn't conclude to just let the user mess about. The challenge is to subtly guide the user, without getting in his way. If you haven't already, you will come to learn that users think visually and they are and probably will always be more interested in their content looking good right there in front of them than on it being all nice and semantic. Depends on the user. The spectrum ranges from those who only care about structure and semantics (perfectly happy with black text on a grey background) to those who only care about looks. The majority is somewhere inbetween. -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] several messages about HTML5
At 21:21 -0500 UTC, on 2007-02-20, Vlad Alexander (xhtml.com) wrote: [...] Is it due to a flaw in HTML that it is difficult to build authoring tools, such as WYSIWYG editors, that generate markup rich in semantics, embody best-practices and can be easily used by non-technical people? I think a big part of this problem is that WYSIWYG does not and never will apply to the Web. Period. As long as you think in those terms, this problem cannot be solved. And as someone else said, most authoring tools still try to be WYSIWYG, and thus fail. That's not a flaw in HTML, because it is essential to HTML that it separates content from presentation. My feeling is that many people can understand and work with that slightly abstract concept, but they need tools that make it easy. Trying to achieve this with a wannabe-WYSIWYG editor is going to be a fight. If we can offer people 'semantic editors' that work in a 'natural' way, they won't have to fight. People will still have to get used to the idea of course. Ian's mention of education applies. But I think before that education stands a chance of making a dent, there'll need to be good non-WYSIWYG authoring tools. Figuring out the right interface for such a semantic editor will be one of the biggest challenges. It'll require teaming up with people in other fields, who have studied how people learn; how minds work. (Sort of like what Apple did when they first designed their GUI.) The Web Repair Initiative aims to take on this challenge: http://webrepair.org/. Since much of the content on the Web is created using such authoring tools, can we ever achieve a semantically rich and accessible Web? IMO it makes it in fact more achievable. Although it will be a quite an undertaking to improve authoring tools, it is still much easier than to succesfully preach to each and every webdesigner out there... I consider this shift towards using HTML generators an opportunity to get closer to a semantically rich and accessible Web. -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] blockquote cite and q cite
At 14:42 +1300 UTC, on 2007-01-07, Matthew Paul Thomas wrote: On Jan 7, 2007, at 7:13 AM, Sander Tekelenburg wrote: [...] It's still entirely unclear to me *why* the cite attribute needs a replacement. What is wrong with it? First, it's hard for UAs to present cite= in a way that is both usable and backward compatible. I'm assuming your unusable refers to the text in parenthesis (below), but it's not clear to me what you mean with backward compatible presentation of the cite attribute by UAs. Are you talking about a new UA version doing something different with the cite attribute than the previous version did? (Just changing a cursor isn't discoverable enough. Agreed. I won't claim I know the solution, although I do think that if a UA would use one single method of indicating that some metadata is available for *any* element/attribute, that might already very well be a usable solution. I doubt it is truly necessary to use different indicators for each and every different sort of hidden meta information. The fact that UI problems like this aren't solved yet does not mean they cannot be solved. Just that they haven't been solved yet. I'm sure that to a large extend this has to do with UA vendors having spent resources on browser wars and ESP engines for the past 10 years, at the cost of other development. Another aspect is that it simply takes time and experimentation to figure out how to do some things 'right'. I consider the Web to still be in its early infancy. Only since about a year or 2 does a relatively large group of users (though still a clear minority) use relatively decent webbrowsers; on the authoring tools front we're not even at that stage. Lastly, it takes users time to get comfortable with new technology. Especially those who grew up before the technology existed. It doesn't seem unlikely to me that a next generation will grow up considering it only natural that digital objects often contain initially invisble properties (and that that is a sensible authoring approach). In other words, I prefer to be cautious about making specs less ambitious as long as there seems to be room for UA and authoring tool authors to improve their products such that the ambitions of current specs are met better. (Also because it's much easier to obsolete a browser (version) than (aspects of) a spec.) Putting any extra button etc in the page might mess up page layouts As might the user's default font-size. Welcome to the reality of the Web. (The way I see it is authors still need to learn liquid design. It's a big mental step from WYSIWYG, so it's natural that this takes time. Having better UAs and authoring tools will help, but even then it may be that, as with so many new things, this will take 10 or 20 years -- the time for a new generation to grow up with liquid design as a natural aspect of life.) , though it might work if it was placed in-line at the end of the quote.) That would seem entirely appropriate to me, yes. Second, it's hard for authors to use it in a way that is backward-compatible. That is, if the source information is important enough that it needs to be accessible in those UAs that don't (yet) support cite=, the author has to provide the information in some other fashion too. Yeah, but as a spec writer you then risk entering the terrain of dumbing down the Web for everyone, just because some people are still using lousy UAs. Some of us feel that such information should be *available* but not *visible* per se, because making it visible will often only lead to distraction from the actual text. Think of the small screens of palmtop browsers. Even on an iPhone you don't want to be forced to waste screen space on cite attribute values. You want that accessible, but only when you want to actually interact with it. (This is the same reason why a while ago I argued for some way to have sites' navigation menus be authored as 'meta data', hidden or hidable -- use space only for content that's actually needed at that moment.) So even just adding some method to mark up the source of quote such that it is presented visually by default, without removing the cite attribute, will likely impover the Web for everyone. *Unless* such markup can be presented as dynamically as the cite attribute can. But I think that would require the spec to state that UAs MUST by default present such content hidden. So returning to your earlier suggestion: | blockquote | p | qrhubarb rhubarb rhubarb/q | [citea href=www.example.comNemo, Works, IV/a/cite] | /p | /blockquote Provided HTML 5 would state that HTML 5 UAs MUST by default hide the contents of an A element in this situation, this might be a solution. But not without that provision, IMO. (Btw, in this case that would lead to the UA presenting 2 empty square brackets. I don't know what the spec should state to ensure such ugliness doesn't happen.) And third, it requires the existence of an IRI of some sort. Often you
Re: [whatwg] Hyphenation
At 20:22 +0200 UTC, on 2007-01-09, Henri Sivonen wrote: [...] * Not knowing Dutch, the example makes me guess that the diaeresis in Dutch has the same meaning as in French (indicate that vowels don't form a diphthong). If this is the case, the interaction of the diaeresis with hyphenation may even be a generalizable rule that could be hard-coded in Dutch-aware hyphenating browsers. Is it a generalizable rule? I don't think you can generalize it like this, because, like many other languages, dutch borrows from other languages (notable in this case would be german). So there are dutch words where the umlaut has a different function and thus the hypenation rule would be different. [But note that, although I speak dutch, that doesn't make me a specialist...] [...] * Not having a language-specific dictionary available in a browser doesn't make things worse than the status quo, so it isn't that big a deal. That's assuming status quos aren't bad :) (I wouldn't want to be a language teacher in this day and age, where, due to computers' restrictions, your students will constantly see bad examples.) FWIW, my feeling is that it would be best if there'd be a defined format for hyphenation rules, and browsers would accept such description files as a plug-in. This would allow each language's specialist to write their rules, and share them, without putting that burden on browser authors. (Browsers could of course still be shipped with such rulesets.) -- Sander Tekelenburg, http://www.euronet.nl/~tekelenb/
Re: [whatwg] Hyphenation
At 02:19 +0100 UTC, on 2007-01-11, Håkon Wium Lie wrote: Also sprach Sander Tekelenburg: FWIW, my feeling is that it would be best if there'd be a defined format for hyphenation rules, and browsers would accept such description files [...] This format exists. It was pioneered by TeX Cool! (I couldn't find a spec though. Could you point to it?) [...] I agree that browsers should read these dictionaries. OK, so given your position ;) that raises the question of why they don't yet :) Just a matter of so many things to do, so little time? Or does this require something to be specced first? However, the dictionaries don't have to ship with browsers -- they can be web resources just like style sheets and images are. I'm not sure they should. I think this is the sort of thing that users should have easy control over and Web publishers shouldn't be burdened with (they're unlikely to be hyphenation specialists, after all). So my thought was more that users could themselves create such files (or, more likely for most users, download someone else's creation) and install it, to have the browser apply them to all content in that language. I think that's the only way to ensure users can get the hyphenation that they consider correct. (Obviously the browser would have to allow multiple hypenation files, for multiple languages, to be installed.) The only reason I suggested that browsers could even ship with them is that doing so would more quickly reach more users; get them aware of and used to such a nicety. Not a necessity. More a means of 'evangelisation', if you will. No doubt the first browser to offer this will generate some buzz ;) -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] blockquote cite and q cite
At 20:12 +0100 UTC, on 2007-01-03, Anne van Kesteren wrote: [...] Well, the reason I started this thread was to provide a replacement / alternative to the cite= attribute as defined for the blockquote and q elements using some terminology the HTML5 proposal already provided. Mostly to make the metadata more visual. It's still entirely unclear to me *why* the cite attribute needs a replacement. What is wrong with it? -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] blockquote cite and q cite
At 13:22 +0100 UTC, on 2006-12-31, Anne van Kesteren wrote:
[...]
I'm assuming you're referring to If a blockquote element is preceeded or
followed by a p element that contains a single cite element and is itself not
preceeded or followed by another blockquote element and does not itself have
a q element descendant, then, the citation given by that cite element gives
the source of the quotation contained in the blockquote element., at
http://www.whatwg.org/specs/web-apps/current-work/#the-blockquote.
So we can drop the unsupported cite= attribute from both blockquote
and q or at least provide a way to have visual metadata.
I can't follow this. It's not clear to me what you mean with unsupported
(not implemented in a useful way by popular browsers perhaps?), nor do I
see how cite a=URI provides a way to have visual metadata that q cite=URI
does not already. (Not to mention that q cite=URI allows authors to provide
markup that can be understood by older UAs.)
(I'm aware
cite= is exposed in some way in some user agents, but that's not really
usable in any way...)
{frown} Why is that not usable in any way?
If your argument is that you'd like to see better support in UAs, I think I
agree with another poster's suggestion of making the spec be more clear (to
UA authors) about how to implement this. Some UA authors are represented in
WHATWG, so I'd think it should be rather easy to find out what they find
unclear about the current spec.
FWIW, I find iCab's implementation quite usable: indicating that metadata is
available by a cursor change when hovering over the data, and allowing to
directly open the cite attribute's URI (in a new window) through the
contextual menu's Show Reference command. (I'm not fond of
'hover-dependancy' like this, but through CSS a more easily recognisable clue
can be added. For instance something like the dotted underline that has
become somewhat common, to indicate title attributes for abbr and acronym.)
--
Sander Tekelenburg, http://www.euronet.nl/~tekelenb/
Re: [whatwg] blockquote cite and q cite
At 16:26 + UTC, on 2006-12-31, Benjamin Hawkes-Lewis wrote: Sander Tekelenburg wrote: [...] I assumed Anne meant something like: qrhubarb rhubarb rhubarb/q [citea href=www.example.comNemo, Works, IV/a/cite] Ah. Maybe, that's what he meant, yes. But I don't see how this offers any advantage over a cite attribute. Quite the contrary, as you say: Which would be backwards compatible, but wouldn't unambiguously connect q and cite. Which is a major disadvantage in my view. Agreed. (Also, I'd expect most authors will simply omit the cite element in this construction, as it likely won't provide any 'obvious' advantage. In turn, that will probably make UA authors not bother to implement this.) [...] [iCab's implementation] Thanks for letting us know about this. I don't have a nice shiny Mac iCab runs on rusty old grey Macs as well ;) [...] If anyone can think of an unambiguous, non-disruptive indicator for cited quotations, I'd happily attempt to add it to my implementation. Why not display the element as a hyperlink? I'm a bit unsure about underlining, since that's already got quite a lot of meanings and potential conflicts. Agreed. -- Sander Tekelenburg, http://www.euronet.nl/~tekelenb/
Re: [whatwg] several messages about XML syntax and HTML5
At 02:37 + UTC, on 2006-12-08, Ian Hickson wrote: On Fri, 8 Dec 2006, Sander Tekelenburg wrote: [...] http://www.whatwg.org/specs/web-apps/current-work/#parsing [...] The error handling for parse errors is well-defined: user agents must either act as described below when encountering such problems, or must abort processing at the first error that they encounter for which they do not wish to apply the rules described below. [...] Well, user agents have the choice to abort processing, that's true. But no Web browser would do that, they'd all follow the error recovery rules. The allowance for aborting is really only there to allow conformance checkers and data mining tools to abort processing (e.g. if they are used in environments where there shouldn't be any errors). OK. Clear. Thanks. I initially thought that that was meant, but got unsure because the next paragraph speaks specifically about conformance checkers. That gave me the impression that the one cited referred specificially to 'browsers'. So based on that, we can say that every HTML5 browser will deal with errors in the exact same way. That would be a great help to get the Web more interoperable. Excellent so far :) But it still leaves the question whether every browser will in fact be HTML5 compliant. Apparently Apple, Mozilla and Opera have that ambition. Smaller ones, like iCab and lynx, will just have to follow. But what about Microsoft? I still have the impression that they can undermine this entire effort by getting people to use authoring tools that on purpose contain errors that result in 'good' looking pages in Explorer, and 'bad' in HTML5 browsers. Simply by producing code that they know will result in 'bad' pages when parsed in accordance with the HTML5 parsing rules. So my question is: am I wrong that this risk exists? And if the risk exists, what are the plans to deal with that situation when it happens? (I name Microsoft because they happen to be in that position today. But the same risk will exist when some other party will be big enough.) -- Sander Tekelenburg, http://www.euronet.nl/~tekelenb/
Re: [whatwg] several messages about XML syntax and HTML5
At 17:05 +0200 UTC, on 2006-12-08, Rimantas Liubertas wrote:
[...]undermine this entire effort by getting people to use authoring tools
that on
purpose contain errors that result in 'good' looking pages in Explorer, and
'bad' in HTML5 browsers.
And how do you imagine Microsoft will get people to use those evil tools?
{shrug} The same way they got them to use other such tools today. Frontpage,
Outlook, Explorer, Word, etc. all frustrate interoperability.
By pointing a loaded gun to one's head?
It doesn't require guns to get people to do most things. Much easier, cheaper
and effective to just make them feel good.
IE7's team have expressed their will to improve web standards support in
their product.
We'll have to see to what extend that will be put in practice. Anyway, as I
said, my point was not about Microsoft specifically (nor did I introduce the
mostly abused word evil), but 'parties that have the power to do such
things'. Microsoft is just the most obvious example of such a party today.
And to not forget, IE7 was released mostly because of the rise of Firefox and
other alternatives. Their share is going up, not down, so even if MS had some
evil intentions it is already to late:
It wasn't too late for Microsoft when Netscape owned 95% of the market. It
wasn't too late for Google to take over the market when Alta Vista was the
main search engine.
no sane developer would use a tool which
produces broken result in 20+% of the browsers.
Have you looked at the Web lately? Whether it is due to insanity or not, the
reality is that some 95% of Web pages has accessiblity problems. *Many* Web
sites still genrate problems when accessed with Safari, Mozilla/Firefox,
Opera, iCab, lynx, IE pre-6, braille and speech browsers, mobile browsers,
spiders, etc. (Especially if you consider more than just HTML. Think of
things like javascript-dependancy, Flash-dependancy, WindowsMedia-depencency,
and even CSS-dependancy.)
--
Sander Tekelenburg
The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] several messages about XML syntax and HTML5
At 16:13 + UTC, on 2006-12-08, Simon Pieters wrote: From: Sander Tekelenburg [EMAIL PROTECTED] [...] But it still leaves the question whether every browser will in fact be HTML5 compliant. They probably won't, at least for the next few years. Right. That's a window of opportunity (for the sort of attack I mentioned) I'm voicing concern about. I agree that it will likely be much harder when all browsers are HTML5-compliant and most authors produce HTML5. But before that? [...] But having a clear spec generally leads to much better interoperability than not having a spec at all. Heh. How could I possibly not agree with that ;) [...] [potential attack on HTML5] I believe you are wrong. That potential risk is much bigger *today* than if browsers implemented the HTML5 parsing model, because the HTML5 parsing model is a compromise between all browsers while being closest to IE. So pages written specifically for IE will probably look better in HTML5 UAs than today's non-IE browsers. Yes, but your written specifically for IE assumes today's IE. [...] I think that if MS change their tag soup parser, they will change it to be more compliant with HTML5, because doing otherwise would break the Web and MS don't want that Right. I'm imagining a browser that is HTML5-compliant, except for some on purpose different behaviour when encountering specific parse errors. Thus showing both existing pages and new broken pages as authors intended, but different from every truly HTML5-compliant browser. [...] If it by any chance *does* happen If this happens it won't be by chance ;) , then I think this will happen: 1. MS change their tag soup parser and break the Web (unlikely). Agreed. 2. Users start using this new browser (unlikely). Disagreed. Most people seem to stick with what they get with the box unless it both [1] makes their lives miserable and [2] they realise that it does. 3. New Web content authored for this new browser breaks in other browsers (including IE6, IE7) (unlikely). Agreed. 4. Other browser vendors find they are incompatible with new Web content and start to reverse engineer this new browser (has happened before, so potentially likely). Yes. That's the guesswork/ESP engine I've been referring to. When that happens, there will again be more browser behaviour differences than just the 2, like today. If a situation does occur where such reverse engineering is needed, will all browser developers do so together? Or will they be competing? It may well seem attractive to be the first to offer a new version that shows such broken documents 'correct'. Similarly, it's unlikely that all other browse vendors will agree about on exactly what moment a specific problem is wide-spread enough to warrant action. (Because not only does that action require resources, it also implicitly means recognition of the tool that generated the problem.) 5. The HTML parsing spec is updated to reflect reality (happens right now, so potentially likely). Agreed, but (re)defining a spec and getting all parties to implement it takes time. (Granted, possibly in a case like this it can be done rather quick.) -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] several messages about XML syntax and HTML5
At 00:45 + UTC, on 2006-12-05, Ian Hickson wrote: [...] [guesswork] The point is the browsers all do the same thing, and that's well-defined and documented [...] if all the browsers do Z, then since the author presumably checked his page with at least one browser, and it did Z, and he didn't correct Y, then the assumption that Z is what Y was supposed to be is IMHO a safe one. OK, agreed. For HTML5 documents that seems a reasonable assumption. (Assuming the browser indeed is HTML5 compliant.) I'm still somewhat sceptical about the reality of this though, as it relies on the author checking the document with at least one HTML5-compliant browser. This reliance would provide Microsoft an easy attack vector on HTML5: give away free authoring tools (or even lure people into paying for them) that produce code that triggers HTML5-compliant browsers to, as per the HTML5 spec, stop processing the document, and have InternetExplorer present such documents as if they're fine. What then? Will every other browser really tell the user that it won't try to interpret what the author might have meant? -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] Authoring tools
At 06:30 -0500 UTC, on 2006-12-05, Mike Schinkel wrote: Sander Tekelenburg wrote: [...] The tools need to be standard and compatible. I can't follow this. In what sense? Tidy is Tidy. AWPS authors can incorporate it into their product. What standard or compatibility plays a role here? By standard I mean referenced in the HTML 5 specification. My opinion is the standard should point to a base level implementation for each major platform/development tool. I disagree. The standard should restrict itsef to defining the *rules* for interoperability. User Agents and authoring tools just need to comply with that. Exactly *how* they achieve that compliance is up to them. I agree with what Lachlan Hunt wrote in the related thread Provding Better Tools: The spec already requires authors and authoring tools to produce conforming documents, and requires user agents to use conforming parsers. It's just that the specific implementations and implementation details are not for the spec to determine. [...] By compatible, I mean these base implementations would need to be compatible with each other, i.e. the .NET parser would need to be compatible with the PHP parser et. al. Other than compatible in the sense of HTML5-conformant, I don't see what sort of compatibility is applicable here. BTW, by tool I really mean developer component. I'm not sure what you mean with that. Would that include something like Tidy? It is the WRI's intention to develop tools (like Tidy, etc.) that can be used by AWPSs [automated Web publishiing systems] to help them output (not just) valid code. Indeed when such a tool is written in another language than the AWPS, that gap will need to bridged. We'll have to see what will be the best approach for that. It may be possible to define a common API; or it may be necessary for the AWPS author to build that bridge himself; it may be possible to port the tool to multiple platforms. I don't see this as the terrain of a HTML spec though. This is about implementation. -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] several messages about XML syntax and HTML5
At 01:22 + UTC, on 2006-12-08, Ian Hickson wrote: On Thu, 7 Dec 2006, Sander Tekelenburg wrote: At 00:45 + UTC, on 2006-12-05, Ian Hickson wrote: [...] I'm still somewhat sceptical about the reality of this though, as it relies on the author checking the document with at least one HTML5-compliant browser. This reliance would provide Microsoft an easy attack vector on HTML5: give away free authoring tools (or even lure people into paying for them) that produce code that triggers HTML5-compliant browsers to, as per the HTML5 spec, stop processing the document, and have InternetExplorer present such documents as if they're fine. Your assumption seems to be that the interoperable handling of HTML documents is to somehow abort processing. This is not the case. Each error has explicitly defined error-recovery behaviour. My mentioning of parsing abortion stems from http://www.whatwg.org/specs/web-apps/current-work/#parsing, which says: The error handling for parse errors is well-defined: user agents must either act as described below when encountering such problems, or must abort processing at the first error that they encounter for which they do not wish to apply the rules described below. Maybe I'm misinterpreting it? -- Sander Tekelenburg, http://www.euronet.nl/~tekelenb/
Re: [whatwg] several messages about XML syntax and HTML5
[I unintentionally sent my previous message off-list. Sorry about that. Am moving this back to the list again. As there's nothing personal in it, I assume that's OK.] At 18:37 + UTC, on 2006-12-04, Ian Hickson wrote: On Mon, 4 Dec 2006, Sander Tekelenburg wrote: [...] [smiley to indicate validity -- frowny to indicate browser has best-guessed] Users are psychologically affected by smiles and frowns, and would be made unhappy if their computer mostly frowned at them. Making users unhappy is not considered a good thing in usability studies. I'd call that an indirect effect on usability at best, but OK. Still, it seems to me the negative feeling stems from the user not understanding the meaning of the 'frowny', not from the frowny itself. It would just indicate to the user that the current presentation of the site is nothing more than the browser's best guess. This is wrong on two fronts. First, it wouldn't indicate that to the user, because the user wouldn't have a clue what the smile was for That applies to every icon. It only gets meaning after the user has learned its meaning. FWIW, I have some experience teaching non-techies to use iCab and they in fact like the frowny/smiley and find it useful -- once they've been informed what it is. [...] (Most users don't care about standards.) They do care about the reliability of their sources, which is the same thing, whether they know it or not. If due to some markup error some content doesn't appear in some situations, or some content is moved/changed such that its meaning changes, that can have a big impact on the user. For Joe Average's blog this may not matter, but for a governmental information site, pricing or specs of items in a shop, a timetable for flight departures, it very likely will. The browser indicating that it is sure of what it is rendering would be a useful aid. Second, it isn't the browser's best guess. HTML5 defines error handling in detail, so it doesn't matter if the page is conformant or not, it's still going to be interoperably handled. Surely you're not saying that HTML5 will define error handling for every possible case a UA may run into? No doubt UAs will run into invalid HTML5 documents, and apply best guesses -- because the user won't accept a this browser refuses to render invalid documents message. That aside, HTML5 UAs will continue to have to best-guess all those billions of existing invalid pre-HTML5 documents. FWIW, iCab has had this feature for some 8 years, maybe longer. [...] You might want to consider what market share iCab has. And IE's market share is due to its usability? :) You don't seriously think that iCab's small market share is due to its frowny/smiley? More likely it is due to many other reasons. (For one. It's targeted at a niche market, by being Mac-only and extremely configurable. For another, up until recently its CSS 2 support sucked (now it rocks). For another, it isn't pre-installed on any OS.) [...] But then you simply implement it so that you get a happy smiley when the page is valid, and nothing at all when it isn't. This would still fail usability testing, though for different reasons. Now the reason is that the user would think the browser was broken, because it randomly, on about 5% of pages, would show a smile. How is that different from that key in the status bar that they see randomly on some pages? -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] several messages about XML syntax and HTML5
At 20:46 + UTC, on 2006-12-04, Ian Hickson wrote: On Mon, 4 Dec 2006, Sander Tekelenburg wrote: [...] [ESP engines] Surely you're not saying that HTML5 will define error handling for every possible case a UA may run into? Yes. In fact, not only will it define this, it already _does_ define this. e.g.: http://www.whatwg.org/specs/web-apps/current-work/#parsing ...covers the parsing of HTML into a DOM, and describes how you handle every single error, including error recovery. OK, that ambition hadn't yet sunken in here. Still, I don't see how this makes it not guesswork. Looks to me like a *formalisation* of the guess work; specifying what is the best guess in situation x. (Mind you, I'm not saying that is't useful, especially since this guesswork is apparently based on research of real, out there in the wild, HTM, and is this intelligent guesswork. But I don't see how, in error situation x, interpreting y as z can ever guarantee that the author did indeed mean z.) Or do I misunderstand something? [...] [browser indicating no guesswork was needed] How is that different from that key in the status bar that they see randomly on some pages? Given the extremely bad usability of SSL UI, and the fact that the security community is currently having to desperately find new ways to make sites secure in a way that users understand, your analogy is actually very apt. There are a number of studies that show that SSL UI is horrendous; one study I read suggests that over 60% of users don't even pay attention to SSL error messages, let alone the lock. Surely your not paying attention is the same as my earlier ignoring? How does the ignorability of the lock icon make it negatively affect usability? (Maybe from the standpoint of those who insist the user must deal with that message, but surely not from the standpoint of the user.) Sure, bugging people with error messages continuously is bad for usability. But an unobtrusive, ignorable icon that conveys something useful? -- Sander Tekelenburg, http://www.euronet.nl/~tekelenb/
Re: [whatwg] Authoring tools (was Graceful Degradation and Mime Types)
be equal to HTML 5 or whatever standard. HTML 5 can include an ESP engine spec; define how certain common authoring mistakes should be treated, so they'll result into something predictable. But there is no way HTML 5 can define everything that people might possibly throw at the Web. To quote a remark you made earlier: (although how to ensure the clueless get a clue, I have no suggestions.) So this option is not very likely to produce good results. -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] Footnotes, endnotes, sidenotes
At 07:04 -0500 UTC, on 2006-11-06, Matthew Raymond wrote: [...] | p annotation=my-footnote | This paragraph has a footnote | a rel=annotation href=#my-footnotesup[1]/sup/a. | /p What if you want multiple footnotes in the one paragraph? p This span annotation=my-footnoteparagrapha rel=annotation href=#my-footnotesup[1]/sup/a/span span annotation=my-other-footnotehas two footnotesa rel=annotation href=#my-other--footnotesup[2]/sup/a/span. /p Like that? | [...] | footnote | pReferences:/p | al | ol | li id=my-footnote | pThis footnote can contain block-level elements!/p | /li | /ol | /al | /footnote [...] The a hrel=annotation and its contents, when the child of an element that has an |annotation| attribute, can be ignored by the user agent and replaced with an annotation-specific presentation. That would be good yes. The spec should then explicitly state that UAs may do this (or perhaps are even encouraged to do this). It would probably be good to provide some examples of possibilities even. If the |annotation| attribute is left off, the user agent can assume that the parent of an a rel=annotation element is the context of the annotation. What I miss in this is something to help users return from the footnote to where they were in the main text. I think we need to consider that a requirement. What about a rev=my-footnote attribute on the al list item, to allow UAs to offer users a mechanism to return to where they came from? (Downside would be that this would revive that old rel/rev can of worms...) Another thing is that whether the annotation should be considered a footnote, endnote or whateverelsenote seems to me a presentational issue, so I'm not that enthusiastic about calling it a footnote element. Why not simply annotation? You can then allow the author to decide where in the page, or in a group of pages, to place the annotation element, and use CSS for the presentational aspects. (You could allow the same with foonote, but that name suggest it must only be used for footnotes.) -- Sander Tekelenburg, http://www.euronet.nl/~tekelenb/
Re: [whatwg] Footnotes, endnotes, sidenotes
At 17:53 +0100 UTC, on 2006-10-31, Håkon Wium Lie wrote:
[...]
W3C recently published a proposal on how to achieve
footnote/endnote presentations using the same markup [1]. The proposal
is quite simple. Given this markup:
div class=note../div
you would achieve footnoes with:
.note { position: footnote }
ane endnotes with:
.note { position: endnote }
I miss the semantic aspect. div class=note has no meaning. Something like
annotation would have. Once that's in place, I suppose you could indeed
offer CSS mechanisms to suggest a presentation as footnote, endnote, whatever.
Btw, I can perhaps vaguely imagine what display:footnote might look like, but
I have no clue what position:footnote might look like. I feel that this sort
of thing needs to be *much* more obvious from a spec, or else only a minute
elite will actually use such features (which in turn will give browser
vendors a reason to not even bother implementing support).
Another problem I have when thinking about the ideal spec for this is that
footnote seems to me very much a print concept, where you have a clear
concept of page. With a screen presentation however, there's the question
whether end of page == end of document, or whether it is the end of the
window (and scrolling takes you to the next 'page').
I mention this because I can imagine that in some situations you'd want notes
to appear at the end of the document, but in other situations it might work
better to have them at the bottom of the window, or at the end of a
chapter/section, which doesn't necessarily equal the end of the document.
Also, given the realities of scrolling, I think a useful implementation would
require a mechanism that allows the user to navigate back from the footnote
to the point in the text that references it. I'm not sure what mark-up this
would require though, especially given that a footnote might be referenced to
from different points of the text. Possibly an anchor-like mechanism would be
simplest, as it would allow a UA to allow the user to simply hit the back
button. (Althought that assumes the UA would go back to the specific point in
the page where the user was before -- some UAs instead still go back to the
top of that page.)
Another thought: it seems to me that something along the lines of the
longdesc attribute[*] might be useful for annotational purposes. The only
implementation I'm aware of is iCab's, which provides access to it through
its contxtual menu and loads the expanded description in a new window. That
too makes it easy for users to return to where they were. The downside of
longdesc of course is that it requires a separate Web page, which would
exclude the possibility of presentating the annotation in the same page.
Perhaps an longdesc-like annotation element should therefore require an
anchor (pointing to an ID within the current page), not allow URLs that point
to external documents.
[*] http://www.w3.org/TR/html4/struct/objects.html#adef-longdesc-IMG
--
Sander Tekelenburg, http://www.euronet.nl/~tekelenb/
Re: [whatwg] input type=country?
At 17:54 +0100 UTC, on 2006-08-24, James Graham wrote: Sander Tekelenburg wrote: A good implementation would [...] A much simpler implementation would simply work like existing form autofill, matching values the values that the user has supplied to other country inputs in the past without needing any explicit setup. Agreed. That would probably work even better/simpler. -- Sander Tekelenburg, http://www.euronet.nl/~tekelenb/
Re: [whatwg] Spellchecking mark III
At 23:56 + UTC, on 2006-06-29, Ian Hickson wrote: [...] On Mon, 12 Jun 2006, Alexey Feldgendler wrote: There's nothing really bad in allowing CSS to control behavior to some extent. CSS is the part of the document that can be disabled/replaced. If disabling the author styles changes the functionality of the page, then that's bad. Agreed. [...] On Thu, 15 Jun 2006, Sander Tekelenburg wrote: [...] Just like authors cannot know what font size is best for a user they cannot know whether a spellchecker is useful or a nuisance. But they can suggest what font-size might be most appropriate. I don't see how allowing authors to abuse one thing is an argument to give them more things to abuse :) I'm well aware that *everything* can be abused, but when something is useful enough then its potential for abuse is a downside you choose to live with. When something is not useful enough, the abusability argument should win. [...] On Fri, 23 Jun 2006, Sander Tekelenburg wrote: [AUTHOR REQUIREMENTS] Authors should set the document's language information, to enable user agents to accurately determine which dictionary to use when checking the spelling or grammar of user input. IMO this should should be a must. What about if the author doesn't know the language? Of the user input you mean? Good point. But then what if a page is in english but accepts input in any language? The author should still indicate the content's language, thereby triggering the wrong spellchecker for those who wish to input text in another language. In turn, the result may well be that authors set no lang attribute at all for the page. Surely a spec shouldn't push authors in that direction? A solution might be to make this a *must* and allow lang=*, so the author can state lang=en on the body, and lang=* on the input field. I still seriously doubt authors will use this as intended though... IMPLEMENTATION REQUIREMENTS All elements can have spellchecking enabled or disabled. UAs may allow the user to set this flag Why may? Why not must? [...] Because you can't require a particular UI. For example, the UA could be a kiosk-style system, where the user is not to have any ability to do anything but enter his text and hit submit. Good point. But if I'm not mistaken HTML 4.01 already says that some things do not apply to UAs that can't implement them. I think you should at least change this to a should, and add a note to the spec that explains that this means user-agents that can should, and only those that can't are excused. (To be clear: my argument is that the spec should do its best to avoid giving user-agents an excuse to not bother giving the user (easy) control.) [...] On Fri, 23 Jun 2006, Lachlan Hunt wrote: I don't particularly like giving the authors any control over spell checking. For the majority of cases, I think browsers should become smart enough to know whether or not to enable/disable spell checking without any explicit author input, based on various heuristics (as I've written about before [1]). In other words, for most cases, authors should not need to use this attribute. The request for this attribute came from a UA in the first place. This would seem to suggest they can't find a way to be smart enough, and would like author input. Not meaning to be disrespectful, but can't suggests it's simply too difficult technically, while it could just as well be that they prefer to take the easier way out, for instance because they can't afford spending the necessary resources on this. That can be a perfectly valid argument for an individual browser vendor, but it's hardly a solid basis for a HTML spec. Especially when the request comes from a single browser vendor and everybody else seems to see more problems than benefits. [...] Ok, so how can we ensure that spell checking is enable for GMail's To: line but enabled for its Subject line? Ordinarily, input type=email would handle no spell checking for email addresses, but given that Gmail uses a textarea that contains both people's names and email addresses, that may be one case where heuristics may not give optimal results. Indeed. So how should we do it, if not using an attribute to hint to the UA whether it should be enabled or not? I can't follow this. If a site uses 2 types of content within the same field and wants one of those types to be spellchecked, and the other not, how is a |spellcheck| attribute going to help? They'll need to split those 2 types of content into 2 different fields. (That aside, I don't see how users would have a problem with spellcheckers indicating spell errors on email addresses or names. Surely they're already used to ignoring that.) [...] since the entire discussion here was spawned by one such browser vendor saying we need a way for authors to control this!, I would suggest that browser vendors have determined that they need a way for authors to control
Re: [whatwg] On accessibility
At 10:29 +0700 UTC, on 2006-06-15, Alexey Feldgendler wrote: [...] Here is what I think should be standardized: a user agent which supports accesskeys MUST provide an uniform method of invoking any accesskey which is a letter or a digit. This method should be designed so that the UA's own key bindings never conflict with the accesskeys. FWIW, IMO this is not the terrain of a HTML spec. That aside, it seems to me that a browser that allows such keyboard-shortcut conflicts to occur is so obviously broken that I don't even understand why it needs to be discussed at all, let alone /here/. *If* you want to go there, the effort should be much broader: you should then also state that browsers must by default indicate the existence of a TITLE attribute; that browsers must indicate when their ESP engine has kicked in so the user knows that what is rendered is at best an educated guess; etc. It might very well be useful to have such a spec -- something along the lines of the GNKSA[*]. It might certainly be helpful to users to have a comparison chart available, maybe with a scoring per browser or even some sort of certification. But I don't see why such requirements should be spelled out in a HTML spec. [*] http://www.newsreaders.com/gnksa/ -- Sander Tekelenburg, http://www.euronet.nl/~tekelenb/
Re: [whatwg] input type=text accept=
At 22:36 +0200 UTC, on 2006-06-09, Anne van Kesteren wrote: Quoting Matthew Raymond [EMAIL PROTECTED]: [...] [...] I don't see the utility of enforcing the use of a specific language via a vocabulary list. It's not about enforcing or preventing submission at all. It's about aiding users. As far as I understand that's what the inline spell checking is for. I do see the use for allowing authors to indicate what language submitted content should be in, so that a user-agent can offer spell-/syntax checking if the user wants to. But I don't see at all why you would want to allow authors to flat out state that a spellchecker should be on or off. Just like authors cannot know what font size is best for a user they cannot know whether a spellchecker is useful or a nuisance. (That aside, you can't rely on user-side validation anyway. You need to do that server-side, after the data has been submitted. Thus by allowing authors to state that a spellchecker must be on, you could end up in a stupid 'loop' when the spellchecker guides the user to do one thing, and the server wants another thing.) -- Sander Tekelenburg, http://www.euronet.nl/~tekelenb/
Re: [whatwg] The link element and display: meta
At 09:12 -0500 UTC, on 2006-01-17, Matthew Raymond wrote: Sander Tekelenburg wrote: At 15:26 -0500 UTC, on 2006-01-10, Matthew Raymond wrote: [...] So what you're saying is that display: meta will basically mean not presented in the body. Well, in the sense that in most browsing situations that would probably be the consequence of presenting something as meta data, yes. Remember that the idea is that authors/users can tell a browser to present certain data in a manner that is consistent across sites. In today's browsers I think that indeed would only be possible by presenting it outside of the body, because each site's body is unique and thus cannot offer such consistency. This is not a presentation. It's the exclusion of a presentation. It would be like me saying everything outside of that telephone both is a location. It's not. The telephone both is a location. Everything outside is the entire universe minus the telephone both. Well, I suppose we could choose to instead define a value chrome for the display property. But I think that name doesn't convey the purpose as well. Also, it just might be that in the future we'll see a browser that works in ways none of us envision today, allowing it to offer such cross-site consistent presentation in the body. I'd rather define a value that makes its purpose clear, than one that assumes a certain environment. [...] What you're talking about is a CSS property value that lets the user agent vendor determine the presentation and functionality. No. Just the presentation. [...] This can be done with new HTML markup. I don't see how. Surely you're not proposing that HTML should start dealing with presentation again? No. I'm suggesting markup that tells the user agent that certain content is intended as list for commands and/or navigation. The user agents may do as they see fit with this information. Ah, I see. Yes, I would agree with that. But I see display:meta as [1] an addition to that - a way to define in more detail how the user agent should present it [2] something that can be useful for more than just navigation menus [...] What happens when you style a non-nav element as display: meta? The user-agent presents that element's data as if it were meta data. This might sound like allowing a potential mess, but I think it doesn't have to. Suppose a user-agent would use a seperate browser window for display:meta. It could render any content there as it can today; it could be made easy to find for the user (through a key combination, a menu item, whatever) and it could ensure consistent presentation across sites by applying the same dedicated Style Sheet to it always. [...] This, of course, will do nothing for HTML5-compliant browsers that don't support display: meta at all. True. But given that authors cannot rely on CSS support anyway that seems irrelevant to me. Huh? In that situation, HTML markup would provide a solution, whereas CSS would not. Well, yes, but limited by the fact that HTML only affects structure and meaning/functionality. CSS can offer additional 'solutions', by affecting presentation. [...] As a result, you essentially have a CSS property that gives link semantics to other HTML elements. No :) CSS doesn't affect semantics, just presentation. So you're pretty much making my case for me... I don't think so. If I understand you correctly, you're saying HTML could define that user-agents may present NAV in a way that is consistent across sites, which would in effect result in allowing them to present NAV outside of the body. I agree with the semantics/functionality of that, but I think it isn't complete enough. It's a bit like HTML not specifying what font size must be used for some element, leaving that up to the user-agent. It's entirely correct for HTML to not deal with font size, but we *do* want to give authors and users a mechanism to affect it. Regard display:meta in that light - offering authors and users a mechanism to affect a presentation, instead of leaving it entirely up to the user-agent. So I think we need both. The HTML you propose, and display:meta to give authors and users a mechanism to affect its presentation. (See also the conclusion at the end of this message.) [...] Some apply to block level elements only, some to positioned elements, etc. A CSS spec would only have to define to what sort of elements display:meta applies. Markup languages don't need to be aware of that. But CSS allows you do define which elements are presented as block or inline, so I don't see your point. The properties in that particular case are being defined as specific to certain CSS display property values, not specific elements. That's true. Thus any element could be set to display:meta, just like any element can be set to any other value of the display property. I still don't see how that would require any markup language to be aware of display:meta though
Re: [whatwg] The link element and display: meta
At 15:39 -0500 UTC, on 2006-01-09, Matthew Raymond wrote:
Sander Tekelenburg wrote:
At 19:15 -0500 UTC, on 2006-01-01, Matthew Raymond wrote:
Sander Tekelenburg wrote:
[...]
No, user agents could construct a link bar using the |rel| values of
hyperlinks.
Exactly. That would in fact be an implementation of display:meta. Rendering
the contents of TITLE attributes in a Status Bar is too.
No they're not. They're implementations of the |rel| and |title|
attributes.
How? I don't see the HTML spec stating how rel or title attributes must be
presented.
Even if they were implementations of display: meta, this
is not the correct forum. The W3C www-style mailing list is.
Yes, I will be coining the idea there.
[...]
Until I can turn items into metadata using display: meta
Nit-pick: you will never be able to do that. Just like P {display:list-item}
doesn't change a paragraph into a list item. It is only *presented* as a
list-item - it still is a paragraph.
[...] you're mixing semantics with presentation
I am? How? Hoe is the idea of display:meta (present non-meta data as meta
data) different from display:table (present non-tabular data as tabular data)?
[...]
A LINKs Toolbar (navigation method would perhaps be a better term, as it
is less implementation-specific) could be hidden by default and presented
only when needed.
So could anything else using the style display: none.
Except that that still requires some in-body mechanism, probably requiring
space and definitely being different on every site, to change that content to
a 'visible' state. The point of display:meta is that instead the data can be
presented in a manner that is consistent (for that user-agent) at every site.
(And that therefore it would need to waste less space.)
Like what I mentioned earlier for mobile devices. That way
such a navigation aid would not take *any* space, unless needed - and it
could take *all* space, when needed. I don't see how you could achieve that
with in-body presentation.
This is a simple matter of DHTML.
How does an end-user control the presentation of any site through 'DHTML'?
Does the ECMA standard define that users can override author javascript with
their own?
Just because something's in the
chrome doesn't mean that you can't do the exact same thing in the body.
Could you share what you mean with the chrome? This discussion is the first
time I hear it used and from the context it is not getting entirely clear to
me what you mean with it.
(In fact, it is the very fact that it would be the
same on every site that makes this possible, because only that allows for
the
user to know it exists even when it isn't shoved in his face. With in-body
presentation that's impossible - every site being different, in-body
presentation requires in-your-face presentation.)
This problem is better solved by markup, though.
Exactly how can markup solve this? I think we're talking about presentation,
which is not the realm of HTML (which is why I agree this is somethin for
www-style).
For instance, what
happens if I use display: meta in my user style sheet?
Assuming your user-agent supports it, it will present the element you
targeted as if it were meta data, instead of in-body.
(Sure, I can see that this will affect presentation of the rest of the body's
content. Just like display:none does.)
What happens if
I use display: block in my user stylesheet to override the meta
value, and it ends up making a page five times bigger because it has a
complex menu system?
Exactly that. The menu would be presented in-body, making the 'page' 5 times
bigger. So what? Today's pages *are* 5 times bigger.
The same thing would happen in any user-agent that doesn't support
display:meta. This is nothing new. Not every browsing environment can present
everything the way another browsing environment can. Not every browsing
environment can display tooltips, for example. This is the entire point of
the Web - being able to exchange content and its meaning, regardless of the
end-user's browsing environment's capabilities.
If that's true, then there's a serious problem with CSS.
I can't follow.
CSS (in combination with HTML and Javascript) is more than flexible
enough to simulate virtually any UI.
But that approach makes (keeps) users dependant on authors' javascripts.
Authors who cannot even know what UI to simulate for a specific end user.
In fact, the other day I saw a page
that emulated the Windows XP desktop.
Which would be a confusing UI for a user who is used to another UI. It would
also not allow for the consistent presentation on different sites, as this
still depends on every site implementing its own UI. Plus it would simply not
be possible to do this in every browsing environment - think of text-only
browsers, a speaking browser, a braille browser, etc. Things like this should
be left up to the user. Something along the lines of this display:meta idea
seems to me
Re: [whatwg] The link element and display: meta
At 19:15 -0500 UTC, on 2006-01-01, Matthew Raymond wrote:
Sander Tekelenburg wrote:
At 01:03 + UTC, on 2005/12/31, Ian Hickson wrote:
[...]
easily solvable, by using rel= on a elements instead of link
elements.
Yes, but only if browsers would support display:meta.
No, user agents could construct a link bar using the |rel| values of
hyperlinks.
Exactly. That would in fact be an implementation of display:meta. Rendering
the contents of TITLE attributes in a Status Bar is too.
(Btw, I don't know if this is in the current Opera, but way back in Mac Opera
5 when we first implemented LINK support, a hack was added that recognised
some standard A link types on a few sites, like Google's search results'
Next link which would then be interpreted as LINK rel=next and presented
accordingly in the LINKs Toolbar. Thus there is, or at least was, a working
implementation of display:meta for LINK elements. It doesn't seem all that
far-fetched to me.)
[...]
If screen real estate is the problem, then why have link-related
chrome at all? If web page authors really cared that much about screen
real estate, they'd just make their lists of hyperlinks take up less
room. Do you honestly mean to tell me that we can trust user agents to
create a link bar smaller than one I could create myself within the page
as a web author?
A LINKs Toolbar (navigation method would perhaps be a better term, as it
is less implementation-specific) could be hidden by default and presented
only when needed. Like what I mentioned earlier for mobile devices. That way
such a navigation aid would not take *any* space, unless needed - and it
could take *all* space, when needed. I don't see how you could achieve that
with in-body presentation. (In fact, it is the very fact that it would be the
same on every site that makes this possible, because only that allows for the
user to know it exists even when it isn't shoved in his face. With in-body
presentation that's impossible - every site being different, in-body
presentation requires in-your-face presentation.)
If that's true, then there's a serious problem with CSS.
I can't follow.
Now, it is reasonably to say we need link bars or similar chrome so
that navigational buttons that have the same function are always in the
same place. If you always click in the same place to get to the root
page, or the parent and so forth, no matter what the web site, then it
does improve the user's ability to navigate.
Indeed, *that* is what I'm trying to say. LINK itself is not important to me.
More comfortable navigation is. And given all the factors and circumstances
involved, my impression is that something like the NAV {display:meta} we
discussed could be a good solution. It would allow authors to provide 1
single navigation menu, not having to worry whether a user-agent supports
display:meta (like authors need to with LINK), and it would allow both
authors and users (and browsers' built-in Style Sheets) to present that
outside of the body, and thus consistently.
The problem is that link has throughly proven that there is little
demand for such usability features from users.
How has that been proven? The fact that the majority doesn't (yet) make use
of something is hardly proof, is it? (Based on how I see people struggle with
WWW navigation I would say there certainly is demand for something like this.
I can't prove it, but it certainly seems obvious to me.)
Btw, that reminds me of something Apple did that I think confirms my idea
that people find it hard to navigate the Web: Safari's SnapBack function
targets exactly that issue.
Look at RSS. Pretty much
everyone supports it, and link is much older.
I don't see how that proves anything. If Navigator and Explorer 2.0 had
supported LINK then probably every single site out there would be using it
today. Authors and users using something, or even *recognising* that they
'need' something is often only made visible after it has been made available
to them.
--
Sander Tekelenburg, http://www.euronet.nl/~tekelenb/
Re: [whatwg] Menus, fallback, and backwards compatibility: ideas wanted
At 00:42 + UTC, on 2005/12/15, Ian Hickson wrote: On Tue, 13 Dec 2005, Alexey Feldgendler wrote: [...] One possible solution that comes to my mind is describing a site map with some tree of nested elements, with page titles, URIs and other meta information, but without any presentational information. As this site map is common for all or most pages of a site, it could be included as an external XML resource. Many people have tried this kind of thing in the past, with little success. As far as I can tell, there is little interest from Web authors in describing their site map (which is more a graph than a tree, and which is getting all the more dynamic with things like wikis). My theory is that there is an inverse relationship between the level of abstraction involved and the level of interest from authors. Site maps in external files are a kind of abstraction beyond most authors. While that is certainly true, at the same time there appears to be a strong trend towards using automated Web publishing systems (CMSs, wikis, blogs, forums, etc.). Such a system will often 'know' already what the sitemap 'is' and could thus probably easily generate it automagically. I think it would make sense to adjust a spec not only to what human HTML authors can/will use, but also take into account what automated systems can/will. (Btw, I don't know if it would have to be a 'sitemap'. The profile attribute to HEAD seems to apply to this.) -- Sander Tekelenburg, http://www.euronet.nl/~tekelenb/
Re: [whatwg] Menus, fallback, and backwards compatibility: ideas wanted
At 20:38 + UTC, on 2005/12/09, Ian Hickson wrote: On Fri, 9 Dec 2005, Sander Tekelenburg wrote: [...] link has had ten years to prove itself. It failed. We should learn from this and not force ourselves to give it another ten years. :-) Indeed we should learn from this, but my conclusion would rather be that what we should learn from it is that we need to be a little bit more ambitious ;) menu is not really primarily for navigation (that's what nav is for). The main use case I'm considering is command menus, as seen in applications like Yahoo Mail, Hotmail, etc. Ah. Maybe I misunderstood your aim then. I got the impression there was also talk of navigation menus in this thread. Is the idea then that nav may contain menu, to define a menu to be for navigation? (I'll assume this for the example below.) Or did I completely misunderstand and is menu not meant to be used for navigation at all? [...] That way web publishers wouldn't need to dupicate navigational links anymore and user-agents could allow users to decide whether to present such menus inline in accordance with the site's suggested presentation (CSS), or in the sort of toolbar that current browsers offer for LINK. I'm not really sure how this would work. Could you give a more concrete specification for your idea? menu attributes: type, etc. type attribute values: - import Informs the user agent that the document's LINK elements are to be imported (as list items) into the menu. If the menu element is empty, user-agents may choose to not draw the menu at all but instead provide access to the LINK elements through a meta mechanism, such as a LINKs Toolbar for example. Example markup: head link rel=home HREF=index.html title=Home link rel=contents HREF=toc.html title=TOC link rel=help HREF=help.html title=Help link rel=search HREF=search.html title=Search link rel=address HREF=address title=Contact /head body nav menu type=import /menu /nav /body The user-agent would parse this as either: body /body and providing access to the LINKs through, for example, a LINKs Toolbar or, if no such LINKs Toolbar is available, as: body nav menu type=import liA HREF=index.htmlHome/A/li liA HREF=toc.htmlTOC/A/li liA HREF=help.htmlHelp/A/li liA HREF=search.htmlSearch/A/li liA HREF=address.htmlContact/A/li /menu /nav /body -- Sander Tekelenburg, http://www.euronet.nl/~tekelenb/
