Re: [whatwg] Persistent SharedWorkers
Drew Wilson wrote on 06/03/09 23:39: >... > - Worker UI: > From the worker standpoint, the main difference between a > PersistentWorker and other types of workers is that the normal way of > interacting with the user (via an open browser window) is not > available, since there may be no windows open to the parent domain. We > have yet to enumerate through all of the use cases, but our initial > brainstorming came up with a few possible types of desired > interactions: > > 1) Display an icon in the OS status bar. This would be an unobtrusive > way for a given domain to display things like "you have new mail" or > even errors like "unable to contact server". Speaking for Ubuntu, we are making active efforts to reduce the number of elements in the notification area (aka "system tray"), with the items remaining there being system-wide things rather than application-specific things. We would not be willing to let Web applications insert icons there. (Similarly, recent versions of Windows have been more aggressive about hiding notification area icons by default.) > If supplied with an > onclick handler, this could also be the footprint for further types of > user interaction: We also plan to make panel elements behave consistently as menus, rather than some being menus and others being buttons, so an onclick handler alone wouldn't work so well even if we allowed the icon. >... > 3) Toast (http://en.wikipedia.org/wiki/Toast_(computing) > <http://en.wikipedia.org/wiki/Toast_%28computing%29>) - behavior is > similar to the showNotification() API that was previously in HTML5. >... > showNotification(url) - displays the HTML at the passed URL to the > user via a toast popup. user agents may put restrictions on the size > of the resulting window. The original HTML5 showNotification() API was much > more limited (a few lines of unstyled text, an icon, and an onclick > handler) - Dmitry Titov makes the case for full-HTML notifications > here: http://docs.google.com/Doc?id=dhg4xn62_28f8cwvzf8 - I have some > concerns about phishing (since there's not necessarily any indication > about the source of a given notification), so that may impact our > implementation. >... Ubuntu 9.04 will feature initial work to ensure that notifications either pop up above other windows, or are interactive, but not both. (This is to avoid accidental clicks, and to allow interacting with whatever is under a popup notification without having to close it first.) Allowing arbitrary HTML in popup notifications would be basically incompatible with that. We would be happy to let Web pages show popup notifications using an icon and unstyled text, but not an onclick handler. Cheers -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg]
On Nov 17, 2008, at 10:05 AM, Ian Hickson wrote: ... On Mon, 21 May 2007, Stijn Peeters wrote: ... It makes sense to clear these values when the field is focused, as the user will probably want to insert a new value rather than edit the value that is currently in it. Currently this is mostly done through javascript, which is not necessarily a bad thing, but seeing that attributes such as autofocus="" have also found their way into the spec, I suppose this is also inside the scope of Web Forms 2 or HTML5. As for the attribute name, clearonfocus="" with "clearonfocus" as the only possible value (indicating the input field or textarea should be cleared upon focusing it) would probably be most suitable. ... On Wed, 23 May 2007, Matthew Paul Thomas wrote: I don't understand. What use is a default value if you can't edit it? Why not make the field empty to begin with? On Fri, 25 May 2007, Matthew Paul Thomas wrote: No, we already addressed the label use case. I asked specifically about the default value use case. I don't know what you are asking for here. I was asking, obviously, what use is a default value if you can't edit it. If an enabled text field had a displayed value= but the value was not actually editable, that would be unpleasantly surprising. That problem applies just as much to as it would have done to : depending on whether the placeholder text is greyed out, it would make the field either look like it has a value when it actually doesn't, or look disabled when it actually isn't. It would also hide the label or hint for the field for *precisely* the period when you need it most. I'm not aware of any possible presentation that avoids both (or even one of!) those problems, and previously HTML5 has shied away from expecting browsers to implement things that have no known reasonable presentation. I appreciate that Web authors currently go to some scripting lengths to position labels for text fields inside the fields, and I think it's quite appropriate that they should have to go to those lengths, because it makes bad design more difficult. I would rather see, as I've previously suggested, markup for associating form controls with hints outside them in a similar way as labels can be associated now. ... On Tue, 30 Sep 2008, Andy Lyttle wrote: ... 3) anybody who is currently using the title attribute doesn't expect it to be displayed as a placeholder, so we would break things for them (especially if their title string is too long to fit inside a small field) We can't really change the behavior of title="" now, it'd have all kinds of weird unexpected effects on existing pages ... On Thu, 2 Oct 2008, Tab Atkins Jr. wrote: ... Of course, it's still not in any way semantic. The only difference between "(optional)" being displayed near the input and being displayed *within* the input is one of aesthetics. The meaning of the document isn't changed one iota. This leans me even more toward a CSS solution. I don't see any harm to having this in the language really. We don't disallow UAs from rendering this after the control. ... But they couldn't really do that, it'd have all kinds of weird unexpected effects on pages designed by people using browsers that present it the way the spec suggests. Cheers -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] ---
On Nov 6, 2008, at 12:32 AM, Eduard Pascual wrote: ... Initially, HTML was entirely structural: no presentation, and no semantics. Just paragraphs, headings, anchors, and few other things. ... The earliest surviving HTML draft from 1992 includes the and elements, both entirely presentational. <http://www.w3.org/History/19921103-hypertext/hypertext/WWW/MarkUp/ Tags.html> HTML+ in 1993 went further: "In many cases it is convenient to indicate directly how the text is to be rendered, e.g. as italic, bold, underline or strike-through". <http://www.w3.org/MarkUp/HTMLPlus/htmlplus_16.html> Those presentational elements continued into HTML 2.0. HTML has always been a dance between structure and presentation. Too structural, and humans won't understand it; too presentational, and computers won't understand it. -- Matthew Paul Thomas http://mpt.net.nz/ ---AV & Spam Filtering by M+Guardian - Risk Free Email (TM)---
Re: [whatwg] Web forms 2, input type suggestions (Michael A. Puls II)
On Oct 29, 2008, at 6:40 PM, Kristof Zelechovski wrote: Declare INPUT[type="mailing-list"] instead of INPUT[type="emails"], please. Type="emails" is ugly and confusing (as it seems to expect messages). ... "emails" is indeed ugly, but "mailing-list" would be even worse. A mailing list usually has a single address. -- Matthew Paul Thomas http://mpt.net.nz/ ---AV & Spam Filtering by M+Guardian - Risk Free Email (TM)---
Re: [whatwg] element comments
Ian Hickson wrote on 30/07/08 04:08: > > On Sun, 14 Oct 2007, Matthew Paul Thomas wrote: >> >> On Oct 14, 2007, at 2:03 AM, Henri Sivonen wrote: >>> >>> I don't think "If both attributes are specified, then the ratio of >>> the specified width to the specified height must be the same as the >>> ratio of the logical width to the logical height in the image file." >>> solves any real problem given what browsers already have to >>> implement, so I'd remove that sentence. >> >> As a real-world example, Launchpad currently stretches the width of >> static images to produce simple bar charts of how much particular >> software packages have been localized. >> <https://translations.launchpad.net/ubuntu> >> >> We have to specify both width= and height= for the images, because >> specifying width= alone causes w3m to stretch the images vertically to >> maintain their aspect ratio. Meanwhile, elsewhere we're using , >> so we should really be declaring our pages to be HTML 5 site-wide. >> >> The sentence Henri quoted would require us to choose between server-side >> generation of every chart image, incompatibility with w3m, or >> non-conformance with any HTML specification. I know w3m isn't exactly a >> major browser, but I don't see any good reason for having to make that >> choice. > > As far as I'm aware, the behaviour you describe for w3m matches what > all the UAs do. Sorry, I was unclear there. Previously we were using markup like this: That gave us the desired result in every browser we cared about, except w3m, which obeys the width= attribute but (because it doesn't do CSS) ignores the style= attribute. So now we include a height= attribute as a fallback: That works in every browser we care about, but would be non-conformant HTML 5 according to the current draft. > I'm not sure that this usage of is one that the spec today > considers valid. Wouldn't be the better way to do this? Indeed it wouldn't, because wouldn't work in w3m at all! It also wouldn't work when JavaScript was off in any other browser (a serious consideration for our user base). And it seems a little excessive to need to construct a when all we want to do is stretch an image horizontally. So to reiterate Henri's point, given that browsers (I assume) have to obey disproportionate width= and height= attributes for compatibility with the Web anyway, I don't see the point of requiring authors to make them match the image's proportions. Cheers -- Matthew Paul Thomas http://mpt.net.nz/ ---AV & Spam Filtering by M+Guardian - Risk Free Email (TM)---
Re: [whatwg] Web Applications 1.0 and Menu Labels
Ian Hickson wrote on 29/07/08 03:21: > > On Fri, 10 Aug 2007, Matthew Paul Thomas wrote: >... >> I'm suggesting that since it is common for entire menus -- or >> toolbars -- to be temporarily irrelevant, such as when focus is in a >> field or pane where they do not apply, there should be a disabled= >> attribute for disabling an entire . >... > My concern is that once we extend this mechanism so that you describe > commands separate from the menus and toolbars that they are found in, > and maybe when we add a way to map keyboard shortcuts to commands, > disabling a toolbar or menu simply won't work, and it'll confuse > authors. > > i.e. I'm hoping we eventually get to a system like: > > > ... > > > > >... > > >... Okay, that seems reasonable. Just so long as that command-centric system eventually appears. :-) Thanks -- Matthew Paul Thomas http://mpt.net.nz/ ---AV & Spam Filtering by M+Guardian - Risk Free Email (TM)---
Re: [whatwg] [WF2] |min| and |max| number of selected |option|s
On Jun 11, 2008, at 1:08 PM, Lachlan Hunt wrote: Christoph Päper wrote: ... When using or one somtimes wants to limit the number of selected check boxes or options. Could you provide some examples of some sites that need to apply such limits, and show how people are currently achieving this? Are there sites that use JavaScript to achieve this now, perhaps by listening for click events on the checkboxes, counting how many are checked and then preventing too many being checked. Or are there sites that count how many are checked onsubmit to ensure there aren't too few or too many? ... <http://www.drugstore.com/qxc44_333181_sespider/sample_center/ sample_center.htm> invites you to choose up to three free samples. Choosing more than three is detected after submission, returning you to the same page with an error message. <http://www.diggerslist.com/register.php> asks you to choose up to three "areas of specialty". This is handled using three option menus containing exactly the same options. Choosing the same option twice or thrice, though probably a human error, is accepted without complaint. <http://www.bbc.co.uk/wales/livinginwales/nameyourhouse/housename.swf> invites you to specify up to three features of your house. The design annoyingly requires each choice to be confirmed separately followed by a "Would you like to choose another?" alert. It is implemented using Flash, though it would be easy to implement in HTML and JavaScript. <http://www.oup.com/elt/global/products/goodgrammarbook/menu/apretest/> invites you to select up to five topics of English grammar using checkboxes. Whenever five checkboxes are checked, all unchecked checkboxes are disabled. It is implemented using Flash, though again it would be easy to implement in HTML and JavaScript. <http://members.c-span.org/Subscribe.aspx> requires you to choose at least one of two alert types, and at least one of five programmes. In both cases, selecting zero is detected after submission, returning you to the same page with an error message. <http://www.nicelabel.com/Products/Product-Selector> invites you to select at least one of four label types. Submitting the form with zero selected is detected using a script that reveals the text "Please, choose at least one option". This text was there all the time, just hidden, so would be confusing in UAs that disregarded CSS. A browser supplied with min= and max= attribute values could provide more consistent and timely error prevention in all these cases. One challenge would be conveying the minimum and maximum requirement where the form's initial selection was outside the allowed range (most commonly where a minimum is required but no options are selected by default); without having the site author's knowledge about where an error message can sensibly be inserted in the page, a browser might need to use tooltips or help balloons instead. Cheers -- Matthew Paul Thomas http://mpt.net.nz/ ---AV & Spam Filtering by M+Guardian - Risk Free Email (TM)---
Re: [whatwg] What should the value attribute be for multi-file upload controls in WF2?
On Jun 20, 2008, at 2:44 PM, Lachlan Hunt wrote: ... In each one, I selected a file named test.txt from within my home or My Documents directory. These are the vaules returned in each browser: Windows browsers: IE 8: test.txt IE 7 mode:test.txt Firefox 2:D:\My Documents\test.txt Firefox 3:test.txt Opera 9.5:C:\fake_path\test.txt Safari 3.1.1: D:\My Documents\test.txt Mac browsers: Firefox 3:test.txt Opera 9.5:C:\fake_path\test.txt Safari 4 (Developer Preview): /Users/lachlanhunt/test.txt ... Since Both Firefox 3 and IE 8 only return the file name, and Opera 9.5 refuses to return the real path anyway, maybe we should define that when there's only a single file selected, it returns just the file name. ... -- Lachlan Hunt - Opera Software If this needs to be standardized for interoperability (though it's not clear to me that it does), it might help to know why Opera goes to the trouble of providing a fake path, rather than providing just the filename as Internet Explorer 7 and Firefox 3 do. Was this needed for Web site compatibility? Even if it doesn't need to be standardized for interoperability, it might help improve privacy if the spec advised browsers not to include the path. It's not obvious that uploading a file will divulge the path, and the path might include information that you'd rather not disclose (such as your full name, if you've used it as the name for your home folder). ... But it really depends what use cases we need to address. Do authors ever actually obtain the file name using JavaScript for anything? If so, what for? With multiple file selection, is it likely they would want to inspect each individual file name for anything, in which case, should we find a way to make it easier to obtain individual file names? ... A related issue, that Web Forms 2 also doesn't seem to address: Should it be possible to select the same file multiple times in the same upload control? (I can imagine use cases for selecting the same file in different upload controls on the same page, but none come to mind for the same file in the same upload control.) If it should be possible, but a Web author wants to prevent it in a case where only distinct files make sense, should they be able to do so? And if so, how? Relying on the browser-provided filename wouldn't be reliable when that doesn't include the path. Cheers -- Matthew Paul Thomas http://mpt.net.nz/ ---AV & Spam Filtering by M+Guardian - Risk Free Email (TM)---
Re: [whatwg] Context help in Web Forms
Ian Hickson wrote on 27/05/08 07:47: > > On Mon, 12 Nov 2007, Matthew Paul Thomas wrote: > >> On Oct 30, 2007, at 6:01 PM, Ian Hickson wrote: >>> >>> On Mon, 13 Jun 2005, Matthew Thomas wrote: >... >>>> Many applications provide inline help which is not a label, and the >>>> same attributes would be appropriate here: >>> for="phone-number">The full number, including country code. >>>> Example: +61 3 1234 5678 >>> >>> How would UAs use this? >> >> UAs likely wouldn't, but scripts could. For example, a form might >> include sparing help by default, with a style sheet hiding more >> exhaustive help (as indicated by rel="help"). Then a script could add a >> small help button after each control that has associated help (i.e. each >> control with name="x" where there exists an element on the page with >> rel="help" for="x"). When a control's help button was clicked, the >> control's help would be shown. >... > The data-* attributes are intended for scripts like this. >... The disadvantage of using a data-* attribute is that more kinds of mistakes would be undetectable by a validator. It would have no idea that (a) the value of the attribute must be the ID of an element elsewhere in the document, and (b) each value must be unique within the document. I wonder if the data-* attribute naming scheme could be classified somehow to allow basic type checking like this. I expect there will be other cases where authors want an attribute value to match the ID of an element in the page. Cheers -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] Review of the 3.16 section and the HTMLInputElementinterface
On May 16, 2008, at 5:50 AM, Jon Barnett wrote:
On Thu, May 15, 2008 at 5:04 PM, Matthew Paul Thomas
<[EMAIL PROTECTED]> wrote:
...
Imagine further that this "iPhone" has no user-visible file system. It
stores music, but annoyingly, the device vendor doesn't want to let
people upload songs to Web sites. What the vendor *does* want to let
people do is upload photos to Web sites, so that they can use sites
like Flickr or even post photos to their Weblogs from the road.
So the "iPhone" vendor implements just for photos.
Is this the iphone's behavior? (earlier you said it doesn't implement
, but here you're saying it's implemented for photos)
No, this is a hypothetical scenario, but I think a highly realistic one.
It's rendered in a Web page as three components: (1) a button for
taking a new photo, (2) a button for choosing an existing photo, and
(3) a thumbnail of the selected photo. There's no "filename": that
wouldn't make any sense, because device has no user-visible files.
The interface for choosing a file isn't particularly important. It's
the style/presentation of the button that triggers that interface
that's in question, or being able to create your own interface to
trigger that file-choosing interface.
So if an author said input[type="file"]::button {width: 100px} (or
whatever the selector turned out to be), what should this device's
browser do? Style both of the buttons as 100px wide? Or both of them as
50px? Or ignore any width completely, on the grounds that the author
probably doesn't know what they're doing?
...
Sure, we agree that tricking a user into typing a filename is somewhat
of a security risk, and browsers have mitigated that. My point was
"disguising" the button that triggers the file-choosing dialog box (or
web-page-like interface, if you will) is NOT a security issue.
...
Agreed. My issue is not with its security, but with its
device-independence.
Cheers
--
Matthew Paul Thomas
http://mpt.net.nz/
Re: [whatwg] Review of the 3.16 section and the HTMLInputElementinterface
On May 15, 2008, at 8:33 PM, Jon Barnett wrote: ... The Yahoo! UI toolkit [1] allows a developer to create a "browse" that looks like whatever he wants it to and can be controlled by javascript pretty much however he wants it to. ... That Yahoo widget uses Flash and Javascript to make all that happen. Adobe isn't going to take this feature of Flash away (Javascript control of a file dialog) and I wouldn't expect browsers to try to block it. The W3C File Upload [2] draft allows for the something similar using plain javascript without the requirement for Flash, and there are already implementations in the wild. ... These aren't features you're going to take away from today's users of popular web applications. Those features are here to stay. Imagine that there is a popular mobile device with a Web browser. Imagine further that this browser is widely used, despite having no support for Flash, no support for W3C File Upload, and not even any support for . I know, I know, this seems unrealistic, because "those features are here to stay", but humor me here for a moment. For ease of discussion, let's call this device the "iPhone". ... One problem with either the Yahoo widget or the File Upload draft is that they both require Javascript to function. If you want these features to be accessible to non-Javascript enabled browsers, we'll need to include it in HTML. It would probably call for a new type with a more specific, flexible presentation (i.e. just a button that can be styled with CSS) Imagine further that this "iPhone" has no user-visible file system. It stores music, but annoyingly, the device vendor doesn't want to let people upload songs to Web sites. What the vendor *does* want to let people do is upload photos to Web sites, so that they can use sites like Flickr or even post photos to their Weblogs from the road. So the "iPhone" vendor implements just for photos. It's rendered in a Web page as three components: (1) a button for taking a new photo, (2) a button for choosing an existing photo, and (3) a thumbnail of the selected photo. There's no "filename": that wouldn't make any sense, because device has no user-visible files. And there's no button labelled "Browse…": that wouldn't make any sense, because -- well, shoot, that label's never made sense on any platform. A Web author couldn't implement anything nearly as useful as this using a new control with a "more specific, flexible presentation" -- and they'd need JavaScript to even come close. The UA, on the other hand, can customize the file upload control based on the accept= attribute provided by the author, the presence or absence of a camera, whether a camcorder is connected, whether a microphone is available, whether available input devices are such that direct entry of a text document is feasible, and so on, all regardless of whether JavaScript is available. I don't see how customizing the look of the file dialog's button is a security risk. Sure, the button might say something malicious, but it still requires the user to browser his local files, choose a file, and click "Open". It's a security risk in those browsers where contains an editable text field, because a page could trick you into typing the pathname of a confidential file into the field, and the button would no longer warn you that it wasn't an innocent text field. In browsers (such as Firefox 3, as Jonas just mentioned) where the field is not editable, the button is safer to style -- but if you're assuming the control contains only one button, you might produce ugly results on devices where it has more. ... If Javascript is as an acceptable requirement, another problem with those solutions is that they require separate POSTs. The Yahoo uploader uses a separate request for each file. The File Upload API has functions like getDataAsHexBinary that, I guess, could put a file's data into a hidden input field, but that data still wouldn't be uploaded the same way regular is uploaded (as multipart/form-data with headers for each file, etc). ... Web Forms 2.0 already defines min= and max= attributes for this purpose. Cheers -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] Proposal: target="_reference"
On Apr 28, 2008, at 9:51 PM, fantasai wrote: Křištof Želechovski wrote: How about target="_guide" instead? A reference is usually lengthy and unreadable; the designer should know better than to treat the poor user with a reference. Or _notification. Most of what Matthew wants to use it for seems to be notifications. I don't intend target="_reference" for notifications; that would be quite inappropriate. Firstly, a notification should appear unbidden, but if an author tried to use target="_reference" in that way, the popup blockers in legacy browsers would ensure it never appeared. Secondly, a notification is typically something you read once and then ignore, so it doesn't matter if it scrolls out of view, while part of the point of target="_reference" is to ensure the resource *doesn't* scroll out of view. And thirdly, it usually makes little sense for a notification to have a separate URL, but this is much more useful for help, terms of service, privacy policies etc. I intend target="_reference" for the purposes I actually described: help, terms of service, privacy policies, and (eventually) footnotes and endnotes. I chose "_reference" because that term roughly covers all those use cases. But if the name is confusing, which it may be, I'd be happy for it to be "_secondary" or something similarly non-specific. How are you supposed to figure out the size of this thing? If it's for footnotes and TOS and errors and help and what's-this all at once.. ... target="_reference" would be inappropriate for presenting errors, for much the same reasons as it would be inappropriate for presenting notifications. The exact presentation is up to the UA, of course, but I imagine a resizable pane at the bottom of the viewport, defaulting to about a quarter of the viewport height or about 12 em, whichever is smaller. (Ideally it would be sized based on the actual height of the linked resource, but that's impractical: impractical for internal fragments because you usually can't tell where the fragment ends, and impractical for external resources because -- just as with target="_blank" -- responsiveness would require showing the pane before the resource finishes loading.) Cheers -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] Proposal: Allow block content inside label element
On May 9, 2007, at 2:27 AM, Matthew Paul Thomas wrote: On May 8, 2007, at 9:06 PM, Kristof Zelechovski wrote: ... From the behavioral point of view: The purpose of a LABEL control is to redirect focus on click. It does not make much sense with a TEXTAREA control that is usually big enough to click upon. ... If a browser redirects focus to a *text field* when you click its , on a platform where that doesn't happen in native GUIs (e.g. Windows, Mac OS, Gnome, or KDE), that's a bug in the browser. Web Forms 2 clarifies this. <http://www.whatwg.org/specs/web-forms/current-work/#label> ... As an update on this: In KDE 4, released in January this year, clicking a text field's label focuses the field. This was not the case in KDE 3. So, it would be appropriate for Konqueror (or, when running in KDE 4, Firefox or Opera) to focus text fields when their is clicked, but not for browsers on other platforms. Web Forms 2 allows this platform-specific behavior. Cheers -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] Proposal: target="_reference"
Philip Taylor wrote on 27/04/08 18:30:
>...
> IE6 supported target=_search and target=_media, to open pages in
> sidebars (closable panes at the side of the browser window). Nobody
> uses those target values (in 130K pages I see 3 pages with either),
> and http://msdn2.microsoft.com/en-us/library/ms534659(VS.85).aspx says
> _media was dropped in XP SP2 and _search was dropped in IE7 ("for
> security reasons"). _reference sounds functionally very similar, so
> how would it avoid those security problems
The problem with _media and _search was that if you gave them an invalid
URL, the resulting error page was in the "My
Computer" zone, but could still be manipulated (e.g. have malicious code
inserted in it) by the remote page. That could be avoided by not
treating error pages as being in the "My Computer" zone. I guess
Microsoft didn't bother with this because they knew that media was going
to be, and search already was, handled differently in IE7 anyway.
> and why would it be more successful in practice?
Because it would be cross-browser.
Cheers
--
Matthew Paul Thomas
http://mpt.net.nz/
[whatwg] Proposal: target="_reference"
target="_reference" immediately for providing help, since the way current browsers treat it -- opening a separate window -- would be an acceptable fallback. (If developers didn't consider it acceptable fallback, they could use script to replace the new-window behavior with fake-popup behavior in legacy browsers.) As a bonus, once it was widely supported, document authors could also start using target="_reference" for footnotes and endnotes. This would be much better than most existing footnote/endnote mechanisms, in that the browser wouldn't scroll or navigate away from the original text while showing the note. This in turn would make it much easier to implement than existing footnote/endnote mechanisms: authors wouldn't need to provide special "Back to article" links, or insert dummy id=/name= attributes to serve as the targets of those links. It would work equally well regardless of where the note text was placed -- at the end of a , at the end of the page, or even on a separate page. And it wouldn't even require adding any new elements or attributes to HTML. ... On Mon, 30 Apr 2007, Matthew Paul Thomas wrote: For example, forms sporting those "By submitting this form you accept our __terms of service__ and __privacy policy__" links I mentioned earlier are quite often sent over HTTPS. These are not cached by mainstream browsers, because the browser vendors have caved to bank Webmasters who threatened to block them if they were too HTTP-compliant. So if such a browser was configured to open those links in the same window, it would necessarily forget everything you'd entered in the form, which would be annoying. Yes, one change (reusing the same window) would also require another (caching forms in session history). I'm ok with both of these! :-) So am I. But without finding a way for browsers to escape the economic trap of losing market share through being blocked by major sites, that's just not realistic. However, target="_reference" would solve this problem resoundingly. You could read through the terms of service and/or privacy policy in the same window, without the form disappearing out of the cache. There would be no more panic, from people with maximized browser windows, thinking the form had disappeared and their input with it. And as a bonus, you wouldn't even need to close the terms/policy window separately from submitting the form. If _blank is allowed, I would prefer the specification to discourage authors from using _blank when another solution is practical (e.g. using a element in the original page), 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). Where would you like such encouragements? I'm worried that the former will get lost easily, Immediately following the definition of _blank. (Where else did you have in mind?) and that the second is basically impossible to implement reliably due to scripting (though Safari tries). ... Safari's designers seem to agree with me that it's helpful even if it's not completely reliable. Cheers -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] Expanding datetime
On Apr 24, 2008, at 10:05 AM, Lachlan Hunt wrote: Ernest Cline wrote: From a practical viewpoint, being able to specify dates before January 1, 1 BC (Gregorian) would allow for historical dates not currently available to be specified in markup of documents concerning history. Such dates do not need to be published on the web in machine readable readable formats. How often to do you need to book a flight, or add an event to your calendar that far back in the past? On a museum's Web site, you might want to search its database of antiquities for those from the Mauryan Empire. In an online encyclopedia, you might want to find people who were alive at the same time as Alexander the Great. On a genealogy site, you might want to publish the family tree of the leaders of the Han dynasty. ...The Y10K problem can also be pushed back by this, but is of only theoretical importance. There are still 7992 years before we need to have a Y10K solution implemented. Thus we can safely leave it to to future generations to solve. ... Yeah yeah, that's what they said last time. ;-) -- Matthew Paul Thomas http://mpt.net.nz/
[whatwg] , , and crossing element boundaries
Keryx Web wrote on 26/03/08 08:44: >... > This is from Thomas Thomassen on WSG's list: > > > As I was working on this I wanted to mark up a list where items had > been added and removed. That's when I realised that you can't wrap up > or in or elements because , and > only allows list items as their direct child. >... Oh, but it's even worse than that. :-) , , and are the three cases I can think of where the appropriate content model could be described as "roughshod" -- there's no logical reason (other than ease of implementation) for any of them to fit neatly inside the element hierarchy of the rest of the document. For example, a couple of lines of an ancient poem might be interpolated by an editor where insects had eaten away at the original manuscript, and those insects had paid no attention to the HTML element hierarchy: ... ... ... ... ... ... ... ... Similarly an editor might insert extra sentences into the middle of a paragraph, and therefore split the paragraph in two to prevent it being over-long: . Conversely, she might remove text from two adjacent paragraphs, and therefore collapse them into a single paragraph: . And a highlighted portion of an essay or article can easily include multiple paragraphs, and/or a whole paragraph plus part of an adjacent paragraph. The real-world things that the , , and elements represent can all cross element boundaries at will, just like the text selection in a Web browser can. But with the current (and all previous) content models for these elements, those effects need to be faked using multiple elements. I don't know what use this observation is. Maybe it means , , and shouldn't be HTML elements, but should be something else instead. -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] accesskey
Michael(tm) Smith wrote: > > Jerason Banes <[EMAIL PROTECTED]>, 2008-01-25 23:41 -0600: > >> Long story short, accesskeys were an idea that worked better on paper than >> they did in practice. They inevitably interfered with normal browser >> operation as well as other accessibility features in such a way as to * >> reduce* the accessibility of many web pages. > > Another long story short: accesskey mark is already in use in a > significant amount of existing content, so leaving it unspec'ed > for implementors does not seem like a practical option -- not if > we care about trying to ensure that behavior of that content is > consistent/ interoperable across UAs. But that's precisely the problem: accesskey= *can't* be consistent and interoperable across UAs, or even across browsers, because browsers compete (amongst other things) on their user interfaces, and therefore they have different user interfaces, and therefore they conflict with different values of accesskey=. If that problem had a good solution, removing the attribute would not have been necessary. The specification could include an explicit statement of the form "UAs must ignore the accesskey= attribute", but any such statement would be in the yet-to-be-written "Rendering" section. >... > Most handsets don't have keyboards or real pointing devices that > let you quickly point and click on links; instead they just have > numeric keypads and "5-way" directional pads that are basically > the equivalent of arrow keys plus an enter key/mouse button. > > In the context of delivering content to those devices, it's useful > to provide numbered access keys for quick access to certain links > on a page -- to save users the time and trouble of needing to use > the 5-way on the handset to scroll to the links and activate them. >... Since most pages that contain links don't also use accesskey=, handset vendors should find a way to allow easy navigation of links regardless of whether the attribute is present. Cheers -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] Context help in Web Forms
On Oct 30, 2007, at 6:01 PM, Ian Hickson wrote: ... On Mon, 13 Jun 2005, Matthew Thomas wrote: Or perhaps , to be consistent with the for= attribute in . This is a possibility, but is it really needed? In general it seems we'd want to encourage authors to put the links near the text and controls to which it applies. Sure, but I don't see how it's different from in that respect: we want to encourage authors to put near the control to which it applies, but already has for=. ( can have weak semantic value even when not related to a particular control, but then so could rel="help".) Many applications provide inline help which is not a label, and the same attributes would be appropriate here: for="phone-number">The full number, including country code. Example: +61 3 1234 5678 How would UAs use this? UAs likely wouldn't, but scripts could. For example, a form might include sparing help by default, with a style sheet hiding more exhaustive help (as indicated by rel="help"). Then a script could add a small help button after each control that has associated help (i.e. each control with name="x" where there exists an element on the page with rel="help" for="x"). When a control's help button was clicked, the control's help would be shown. Another possible presentation would be reserving whitespace to the right of the form, and making visible in that space whenever was focused. <http://uxmatters.com/MT/archives/000191.php> shows these and other examples of dynamic help. The cite= attribute was also mentioned in this thread as one that is practically useless because there is no good way of presenting it. (Sometimes authors use JavaScript to pull it out of a and present it as a link underneath. But that still has accessibility problems, because it doesn't work without JavaScript, and the resulting link text is either a raw URL or the same text for every quote. These problems make the technique even more unworkable for .) As a result, authors usually use an link to the resource they're quoting (look at most self-hosted Weblogs for examples), and there ends up being no machine-readable connection between the link and the quote. This could similarly be achieved in the element with a for= attribute giving the ID of the or element. Interesting idea. The majority of authors still wouldn't use these attributes, because it would give them no presentational benefit. But at least authors would be slightly more likely to use them than to use attributes that they have to re-present using extra elements or JavaScript. We should probably aim higher than that though... ... I'm suggesting either replacing with rel="citation" for="id-of-foo">, or dropping cite= altogether. Cheers -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] Element
On Nov 4, 2007, at 5:59 AM, Keryx Web wrote:
Matthew Paul Thomas skrev:
To allow this on the Web, the CSS font-style property would need to
have not just "normal", "italic", and "oblique" values, but also an
"italic-inverse" value. Browsers should then use this value by
default for any inline element where they currently use "italic".
No problem!
i {
font-style: italic;
}
i i {
font-style: normal;
}
...
We're getting off-topic here, but ... That wouldn't deitalicize
, , , , , or , when it
should. As the levels of nesting increased, the number of permutations
of these elements would explode. And it's not reasonable to expect any
author who uses "someblockelement {font-style: italic;}" to remember to
also define "someblockelement cite, someblockelement dfn,
someblockelement em, someblockelement i, someblockelement var
{font-style: normal}".
Cheers
--
Matthew Paul Thomas
http://mpt.net.nz/
Re: [whatwg] Element
On Oct 30, 2007, at 1:04 PM, Krzysztof Żelechowski wrote:
...
Do EM elements accumulate? They are idempotent under the default style
sheet because you cannot make an italic typeface more italic.
In non-Web typography, any text that would be italicized when the
surrounding text is roman is typically printed as roman when the
surrounding text is italic. (For example, academic journals often
feature a mini-biography of each article's author. When the journal's
style is to present the mini-biography in italics, any book title
mentioned therein will usually be in roman.)
To allow this on the Web, the CSS font-style property would need to
have not just "normal", "italic", and "oblique" values, but also an
"italic-inverse" value. Browsers should then use this value by default
for any inline element where they currently use "italic".
But do they accumulate in principle? If they do, is the default style
sheet correct with respect to the EM element?
...
Occasionally I've seen an emphasized word inside an emphasized
sentence. And stories for young children sometimes have sentences that
become progressively more emphasized; this is usually indicated by
increasing the font size.
So a more helpful default would be something like:
em {font-style: italic-inverse;}
em em {font-style: bold;}
em em em {font-size: 1.2em;}
Cheers
--
Matthew Paul Thomas
http://mpt.net.nz/
Re: [whatwg] , , , ; Re: Presentational elements in Web Applications 1.0
On Oct 30, 2007, at 4:33 AM, Ian Hickson wrote: ... On Sun, 15 Jan 2006, Matthew Paul Thomas wrote: ... Authors should use presentational markup whenever there is no available semantic markup for the relevant meaning, or when they are providing authoring facilities for people who cannot be expected to think about semantic markup (e.g. people using Webmail, or people posting comments on the author's Weblog). If authors -- or specifications -- try too hard to use a semantic element, or to force other people to use it, it will be misused so much that UAs can no longer trust the element to have any particular meaning, so it will become de facto presentational. True... but it's not clear if elements like and are the best way of addressing this. Right, because there's no semantic element that their absence tempts people to use instead. (Whereas omitting and would tempt people to use for italics and for bold instead.) ... This has always been presentational, and will continue to be so in the majority of HTML 5 documents. Most authors will assume it has the same purpose as it did in previous versions of HTML; and many of the authors who actually read that part of the spec will giggle at the "instance of a term" frippery and disregard it. This has changed since you commented on it, I believe. Now it's still "presentational", but it is at least media-independent, being defined in a way that is still usable in speech contexts. Yes, the current definition makes much more sense, though it buries the point a bit. I think it would be more obvious to begin something like "The i element represents a span of text where the typical typographical presentation is italics, and no other element is more appropriate. (For example, citations should instead use the cite element..." ... (I strongly feel that there is a difference between used for grouping thematically related blocks, and used for separating thematically related inline content, e.g. parts of a form. ... Launchpad.net presents (for people registered) many forms where a text field has not just a label, but also an explanatory caption of one or two (or in one case five) sentences. These captions are unambiguously paragraphs , inside form rows , inside forms . If we wanted to "separat[e] thematically related ... parts of a form" we wouldn't use ; we'd use , because that's *exactly* what is for. Cheers -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] element comments
On Oct 14, 2007, at 2:03 AM, Henri Sivonen wrote: ... I don't think "If both attributes are specified, then the ratio of the specified width to the specified height must be the same as the ratio of the logical width to the logical height in the image file." solves any real problem given what browsers already have to implement, so I'd remove that sentence. ... As a real-world example, Launchpad currently stretches the width of static images to produce simple bar charts of how much particular software packages have been localized. <https://translations.launchpad.net/ubuntu> We have to specify both width= and height= for the images, because specifying width= alone causes w3m to stretch the images vertically to maintain their aspect ratio. Meanwhile, elsewhere we're using , so we should really be declaring our pages to be HTML 5 site-wide. The sentence Henri quoted would require us to choose between server-side generation of every chart image, incompatibility with w3m, or non-conformance with any HTML specification. I know w3m isn't exactly a major browser, but I don't see any good reason for having to make that choice. Cheers -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] lede element
On Oct 2, 2007, at 7:02 AM, Devi Web Development wrote:
...
Usage Case:
Burmese monks 'to be sent away'
Thousands of monks detained in Burma's main city of Rangoon
will be sent to prisons in the far north of the country, sources have
told the BBC. About 4,000 monks have been rounded up in the
past week as the military government has tried to stamp out
pro-democracy protests. They are being held at a disused race course
and a technical college. Sources from a government-sponsored militia
said they would soon be moved away from Rangoon...
In that example from BBC News, the paragraph is actually four
paragraphs. <http://news.bbc.co.uk/2/hi/asia-pacific/7022437.stm> BBC
News always puts a element around the first paragraph of a story.
But they also bolden the second paragraph, if it's explaining the
source of the story: ...
<http://news.bbc.co.uk/2/hi/asia-pacific/7018411.stm>
So to satisfy the use case of the BBC, would need to be a block
element. I haven't found any examples where it would be an inline
element.
My local newspaper uses a similar pattern:
<http://www.stuff.co.nz/stuff/nelsonmail/4223173a6510.html>
(To future readers: this link probably will have died in a few months.)
Same with ZDNet News, who forget the tags entirely:
<http://news.zdnet.com/2100-9584_22-6211357.html>
Except where BBC News boldens the second paragraph, these examples
could all be satisfied by CSS to select the first paragraph inside the
article container. I doubt any news site would deliberately make the
lede a paragraph other than the first one ("burying the lede") *and*
want it specially formatted.
Cheers
--
Matthew Paul Thomas
http://mpt.net.nz/
Re: [whatwg] Web Applications 1.0 and Menu Labels
On Aug 7, 2007, at 9:10 AM, Ian Hickson wrote: On Mon, 22 Nov 2004, Matthew Thomas wrote: ... Given that, I approve of giving menus and submenus a "disabled" attribute that would make all their descendant items unavailable without forgetting the erstwhile availability of individual descendant items. This attribute would relieve applications from having to remember the particular subset of descendant items that were previously available, during those occasions when they are all temporarily being made unavailable (for example, a "Format" menu while focus is temporarily in a plain-text field secondary to the main rich-text area). The idea of the current mechanism, though, is that you can have those same menu items also be a toolbar elsewhere (say), so you'd want to disable the buttons anyway. Wouldn't it be better to have the menus automatically disable submenu titles when appropriate? It would be good for UAs to dim menu/submenu titles whenever all their items are disabled, if that's the platform UI convention (and perhaps even if it isn't). However, that's orthogonal to my suggestion. I'm suggesting that since it is common for entire menus -- or toolbars -- to be temporarily irrelevant, such as when focus is in a field or pane where they do not apply, there should be a disabled= attribute for disabling an entire . When this attribute is present, all the 's items should be disabled, regardless of their individual disabled= attributes; when the 's disabled= attribute is removed, the disabled= attributes of the individual items should retake effect. This would save authors a lot of work that they might otherwise not bother with, thereby making their interfaces more responsive. I do not think "but the menu items might be duplicated in a toolbar" is a strong counterargument. If the temporarily-irrelevant items are a subset of the items a toolbar, then yes, they will need disabling individually. But often it will be the entire toolbar that needs disabling, or the menu will not have equivalent items in a toolbar, or -- even more common in Web apps -- the toolbar will not have equivalent items in a menu. (Note that the Mac OS X guidelines seem to no longer have the quote you give above.) ... Yes, they now say the opposite! I think that's a mistake, but in any case, that doesn't affect my suggestion. It would still be useful to make an entire menu disabled even if the platform UI convention is for disabled menu titles to look enabled. Cheers -- Matthew Paul Thomas http://mpt.net.nz/
[whatwg] Corrections and clarifications to the WhatWG charter
On May 17th in #whatwg, Ian said: http://www.thewebcreator.net/2007/04/16/why-you-should-be-using-html -401-instead-of-xhtml/#comment-23 (same article) the last comment on that blog entry highlights one of the weirdest things i've repeatedly seen on the web "HTML 5.0 vs XHTML 2.0 (commercials companies vs W3C)" the idea that the W3C, which you have to pay thousands of dollars to to become a member, and which is entirely member-driven, is somehow less "commercial" than the WHATWG, which can be joined by anyone I've also seen this occasionally, and it occurs to me now that the WhatWG Web site may be to blame. <http://www.whatwg.org/charter#member> says: Membership is by invitation only, and consists of a number of representatives from various browser manufacturers. This group, which is referred to as the members, will provide overall guidance as described in the charter above. This is trivially false: the member list includes Dean Edwards, who is not a representative of a browser manufacturer. More importantly, though, it does not make clear the difference between a WhatWG member and a W3C Member. And it apparently precludes, for example, accessibility aid developers from being invited as members. Another problem with the charter itself is in this section: During development, the working group may decide that a document has reached a stable stage and is in need of wider review. At this point the document will be archived in its current state, and a call-for-comments will be announced. Drafts in this stage should bear a warning informing readers that the specification is not considered ready for non-experimental implementations, and that experimental implementations of the draft must not be included in end-user products. Such a warning would undoubtedly be ignored, which would reflect poorly on the specification. For example, browser vendors would not suddenly remove the support they already include in end-user products because a call-for-comments had been issued for the specification. The warning that is currently used in the HTML 5 specification itself is much more realistic: "Implementors who are not taking part in the discussions are likely to find the specification changing out from under them in incompatible ways." Finally, the charter should be updated to refer to HTML 5 rather than Web Forms 2.0 and Web Applications 1.0. Cheers -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] Content-Type (was Style sheet loading and parsing
On May 23, 2007, at 2:05 PM, Sander Tekelenburg wrote: ... 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, <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. 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.) ... Long ago, when Mozilla was told to open a link in a new window, it would fetch the Content-Type to see whether the resource was actually one that should be handled by a helper app instead. Mozilla browsers don't do that any more, and nor does any other browser I know of, because it made for a horrid user experience. Cheers -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] [WF2] Clear On Focus attribute
On May 23, 2007, at 12:31 PM, Charles Iliya Krempeaux wrote: ... On 5/22/07, Matthew Paul Thomas <[EMAIL PROTECTED]> wrote: On May 22, 2007, at 3:35 AM, Stijn Peeters wrote: It is becoming increasingly common to have an input field clear its value when it is first focused. Though in a lot of cases this is actually wrong usage of the value="" attribute for something which should actually be done with (such as a search box filled with "Enter search query here" that becomes empty when you first click it), Indeed. it is possible to come up with legitimate use cases; the first thing that comes to mind are input fields with placeholder or default values that may need to be changed. This goes well together with WF2's new abilities for prefilling forms. It makes sense to clear these values when the field is focused, as the user will probably want to insert a new value rather than edit the value that is currently in it. ... I don't understand. What use is a default value if you can't edit it? Why not make the field empty to begin with? It's a Usability issue mixed with a Graphical design / aesthetics issue., You need a label for the field... but don't want to put one beside it. So the label goes inside the field... until you click on it. (At which point the label disappears.) ... No, we already addressed the label use case. I asked specifically about the default value use case. -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] [WF2] Clear On Focus attribute
On May 22, 2007, at 3:35 AM, Stijn Peeters wrote: It is becoming increasingly common to have an input field clear its value when it is first focused. Though in a lot of cases this is actually wrong usage of the value="" attribute for something which should actually be done with (such as a search box filled with "Enter search query here" that becomes empty when you first click it), Indeed. it is possible to come up with legitimate use cases; the first thing that comes to mind are input fields with placeholder or default values that may need to be changed. This goes well together with WF2's new abilities for prefilling forms. It makes sense to clear these values when the field is focused, as the user will probably want to insert a new value rather than edit the value that is currently in it. ... I don't understand. What use is a default value if you can't edit it? Why not make the field empty to begin with? Cheers -- Matthew Paul Thomas http://mpt.net.nz/
[whatwg]
On May 18, 2007, at 12:43 PM, Lachlan Hunt wrote: ... * class="search" The aim of this one was to be able to indicate the form specifically used for searching. This would then allow UAs, especially assistive technology, to implement keyboard shortcuts or other mechanisms for taking the user directly to the search form. role="search" is provided by the role attribute spec for a similar purpose, and Safari also has . I would prefer the new input type because it also has direct benefits for regular users, not just those with assistive technology. ... I agree, why not add ? The use cases are: * Better accessibility, as described above by Lachlan. * People often scan Web pages looking for "the little box where I can type". <http://www.useit.com/alertbox/20010513.html> If site search fields were visibly different from other text fields, and different *in a consistent way across sites*, that would make people faster at using those sites. There are also ill effects from it *not* being standardized. Web authors often use brittle CSS in an attempt to emulate the Mac OS X or Windows Vista search field look. <http://www.widgetbox.com/widget/rounded-search-box> <http://brandspankingnew.net/archive/2005/08/adding_an_os_x.html> <http://urlx.org/search.live.com/f3835> (see the top of the page) They're brittle in the sense that they have cosmetic differences from the native controls, they sometimes rely on JavaScript, they fall apart when the page is zoomed, and/or they don't zoom at all. (Safari's implementation in 1.3/2.0 also doesn't zoom, but that could be fixed much more easily in WebKit -- if it hasn't been already -- than in a CSS+PNG+JS imitation.) I can think of one potential problem, that being Web authors trying to use for fields that aren't search fields because they think it looks cool (and because they don't use assistive aids themselves, so they don't realize the silliness). That problem would be inversely proportional to how much browsers made the field behave unalterably like a search field. <http://urlx.org/brandspankingnew.net/564a7> * class="error" The original idea for this was for indicating error messages, particularly related form fields. The problem is that screen readers, when in forms mode, only read the content of form control labels, which has resulted in authors having to write any error messages within labels, which is kind of a hack. Labels and error messages should be able to be separated and providing a way to specifically indicate them would allow screen readers to indicate their presence to the user and read it on request. ... Maybe that should be addressed (in Web Forms 3?) with a specific for=...> element. Cheers -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] Proposal: Allow block content inside label element
On May 9, 2007, at 10:28 PM, Křištof Želechovski wrote: The restriction on LABEL behavior is not a clarification, it is a change. Sorry, that was a poor word choice on my part. By "clarifies this" I meant "makes this more accurate", not "makes this more precise". If you know of any non-contrived Web applications that are broken by this change, I'd be fascinated to see them. The browser vendor has to choose whether it is compliant with version 4 or 5. Therefore the current behavior can hardly be called a bug. It seems to be a bug in the HTML 4 specification. The relevant paragraph says: "When a LABEL element receives focus, it passes the focus on to its associated control. See the section below on access keys for examples." Obviously they were thinking about access keys, and maybe they were thinking about voice interfaces too, but not mentioning them specifically so as to convey an aura of media-independence. I would be very surprised if they were thinking about clicking on the label, since no native GUI worked that way (and ten years later, still none do). Note that this change is not reported on the Wiki <http://wiki.whatwg.org/wiki/Changes_from_HTML4#Changed_Elements>; I did not update the content because I strongly oppose this idea. No openly-editable wiki page can be normative. It seems it has strong support <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2004-July/ thread.html#1366> - where Mr. Raymond's opinion unfortunately sank - but there is a possibility to overthrow it by making it void on a legal basis: The Microsoft Windows environment does not provide a native LABEL control.* ... That's not true. For example: <http://urlx.org/microsoft.com/7354a> Cheers -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] Proposal: Allow block content inside label element
On May 8, 2007, at 9:06 PM, Kristof Zelechovski wrote: ... From the behavioral point of view: The purpose of a LABEL control is to redirect focus on click. It does not make much sense with a TEXTAREA control that is usually big enough to click upon. ... If a browser redirects focus to a *text field* when you click its , on a platform where that doesn't happen in native GUIs (e.g. Windows, Mac OS, Gnome, or KDE), that's a bug in the browser. Web Forms 2 clarifies this. <http://www.whatwg.org/specs/web-forms/current-work/#label> Cheers -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] Target Attribute Values
On May 5, 2007, at 12:45 PM, Maciej Stachowiak wrote:
On May 4, 2007, at 4:48 PM, Sander Tekelenburg wrote:
At 01:32 -0700 UTC, on 2007-05-04, Maciej Stachowiak wrote:
...
[...] 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.
...
We already have quite a few link click modifiers taken, including
Cmd-Opt-click. I'll make a feature suggestion to add something.
...
In Safari, as in Firefox, you can already ensure a link opens in the
same window by dragging it and dropping it on the address field. So
there are multiple reasonable ways for a UA to implement it, just as
there are multiple reasonable ways for a UA to indicate whether a link
is specified to open in a new window in the first place. So it is fair
for HTML5 to encourage those things, but beyond that, this discussion
may be getting a bit off-topic.
Cheers
--
Matthew Paul Thomas
http://mpt.net.nz/
Re: [whatwg] Target Attribute Values
On Apr 28, 2007, at 11:37 PM, Smylers wrote: Spartanicus writes: ... Would perhaps a spec conformance requirement that browsers should offer users a config option to opt out of windows being opened via target values be an alternative? ... But _requiring_ user agents to offer opt-outs seems excessive, and possibly beyond the jurisdiction of the spec. It seems likely that user demand will lead mainstream web-browsers to offer options like this anyway, ... Actually they probably wouldn't, because it would break the Web in ways that weren't obviously the result of the option being set. And every option has some people who set it accidentally. For example, forms sporting those "By submitting this form you accept our __terms of service__ and __privacy policy__" links I mentioned earlier are quite often sent over HTTPS. These are not cached by mainstream browsers, because the browser vendors have caved to bank Webmasters who threatened to block them if they were too HTTP-compliant. So if such a browser was configured to open those links in the same window, it would necessarily forget everything you'd entered in the form, which would be annoying. but if somebody wanted to produce a web browser that, say, was so minimalist it didn't offer any user preferences at all, surely that's up to the browser manufacturer? There are already many Internet kiosks that provide no user-visible options at all. But then, sometimes they don't offer multiple windows either. ... Surely whether target="_blank" or even target="help" is treated different from target="top" can at best be a hint? Surely it isn't a requirement of HTML that user-agents implement multiple content windows? That may not be appropriate for some environments, perhaps: ... Yeah, it limits the Web to those UAs for which multiple top-level browsing contexts make sense. Breaking the Web vs. limiting access to the Web, ugh. If _blank is allowed, I would prefer the specification to discourage authors from using _blank when another solution is practical (e.g. using a element in the original page), 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). -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] Target Attribute Values
On Apr 28, 2007, at 5:29 PM, Bill Mason wrote: ... I can tell you my experience at the company I'm currently working for, as to why they mandate using "_blank" in some circumstances. (Disclaimer: I don't endorse the policy, I just have to live with it.) ... 1) Fear that the user will follow some link away from our pages, and never return to complete the form. (I think this comes from sales and/or marketing personnel.) A common solution to that is to minimize links on the form, even to the point of removing most global navigation. Sometimes form-specific links are necessary (e.g. "By submitting this form you agree to our __terms of service__ and __privacy policy__"), but links like those should use named targets rather than _blank (because if someone opens one of those links twice it's a mistake, they don't actually want two copies open). 2) Complaints from users who would follow the surrounding links elsewhere and then lose their way back to the application form. (This would primarily occur when they started the application form -- which is typically multiple pages -- and go off following some other link to find some piece of information about the application process, finally losing their way to how they got into the form in the first place.) In both cases, I have no idea why the back button isn't enough for everyone involved, or how people got lost in spite of having a back button. ... Because the Back button is a horribly awkward interface for navigating, especially for getting back to pages you visited a few minutes ago. (In some browsers the Back button has a visible associated menu, but it's hard to open -- and it relies on page s, which readers probably didn't notice when first scanning those pages, again because of poor browser design.) Cheers -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] Target Attribute Values
On Apr 28, 2007, at 4:12 PM, Maciej Stachowiak wrote: ... One valid reason to use _blank instead of a named target to open a new window is the fact that the top-level frame namespace is global, and you don't want to collide with windows opened by other web apps, or even other instances of your own web app. ... Ever since I first visited two Web pages that accidentally opened external links in the same window as each other, I've assumed that the top-level frame namespace being global was a bug, with under-specification of the target= attribute in HTML4 as a contributing factor. I suggest that WA1 specify that the frame namespace is per-top-level-browsing-context, not global. (Even if it is global in all extant browsers, I doubt that any applications rely on that behavior.) Otherwise, what is a Web application developer supposed to do to ensure that the application's help links reuse only its own help window, and don't accidentally obliterate those of other apps or even other open windows in the same app? Generate a per-page UUID prefix for all its target= attribute values? :-) -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] Target Attribute Values
On Apr 26, 2007, at 7:34 PM, Lachlan Hunt wrote: ... Why is _blank still considered a conforming value? On IRC, Hixie mentioned that there are some legitimate use cases, but didn't list any. I've argued against popups many times before and heard many arguments for them, but I'm yet to hear of any legitimate use cases. If there are any, what are they? ... For most desktop applications in-depth help is presented in a separate window, so this will also likely be desirable for Web applications that do not consist of scrollable pages. (In those that do consist of scrollable pages, help would generally be better embedded in the pages themselves, perhaps as expandable sections.) So that's a use case for popup windows, but not necessarily a use case for _blank, because help windows are usually reused (akin to target="myappnamehelp" rather than target="_blank"). -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] Alt text authoring Re: Conformance for Mail clients
On Apr 19, 2007, at 10:47 PM, Charles McCathieNevile wrote: ... For the various reasons discussed in this thread, I cannot think of a real justification for making a mail client that breaks one of the basic accessibility features that people understand better than most others. And I can think of plenty of reasons for not doing so. ... As Benjamin said, it's worthwhile entering alt= text when sending to many recipients, and/or to unknown recipients; that is why alt= is important for public Web pages (where you don't know who is going to read a page) and for Intranets (where if a blind person joins the company tomorrow, they shouldn't be impeded by lack of alt= text on existing pages). But it seems likely that the vast majority of non-spam e-mail messages are sent to individuals who are known by the sender to be fully-sighted. In that case putting up an interface for entering alt= text, *just in case* the recipient gets struck blind before they get around to reading the message, seems a bit unreasonable. It would also be weird for a mail client to ask for alternate text for images in HTML messages (because HTML requires it), but not for images in multipart/mixed plain-text messages (because there's nowhere to put it). -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] several messages about HTML5
On Feb 21, 2007, at 10:00 AM, Vlad Alexander (xhtml.com) wrote: 4. One of the biggest problems with HTML is that content authors can get away with writing "tag soup". As a result, most content authors don't feel the need to write markup to specification. When markup is not written to specification, CSS may not get applied correctly, JavaScript may not execute and some user-agents may not be able to process content as the author intended. Why not put an end to "tag soup" by requiring user-agents to only accept markup written to specification? ... Because UA vendors compete, in part, on what proportion of Web pages work in their UA. Therefore, in the absence of greater opposing forces, competition will force them to ignore any requirement that they refuse to render a particular page. ... 6. The font element is a terrible construct, primarily because content creators using authoring tools use the font element instead of semantic markup. The X/HTML 5 spec supports the font element when content is authored using WYSIWYG editors. What is the rationale for this? Why would WYSIWYG editors get an exemption? Because most people, including the vast majority of those using Wysiwyg editors, will never bother producing accurate semantic markup, and trying to force them to do so will cause them to misuse it. And is this exemption going to make the Web less accessible? Hopefully more accessible, because in those cases where semantic markup is used, UAs will be able to start relying on it being accurate. ... 8. The chair of the HTML Working Group at W3C, Steven Pemberton, said "HTML is a mess!" and "rather than being designed, HTML just grew, by different people just adding stuff to it". Since HTML is poorly designed, why is it worth preserving? For the same reasons English is worth preserving. ... 9. Supporters of X/HTML 5 call XHTML 2 radical. History has shown us that radical technological change is often controversial, but in the end is the best choice. For example, in the last 40 years, the technology for delivering music has change radically, from vinyl, to cassette, to CD, to purely digital. Why should the Web shy away from a radical technological change? ... For the same reasons people shy away from learning Esperanto. Vinyl, cassettes, and CDs are not languages. Cheers -- Matthew Paul Thomas http://mpt.net.nz/
[whatwg] Use cases for style= on arbitrary elements
I've just encountered a couple of use cases for the style= attribute on arbitrary elements, rather than just . (Sorry this isn't part of the relevant thread, as I haven't kept it.) We have a set of things, stored in a database and listed on a Web page, where we want to indicate their age by making the older ones "fade away". This would be done by computing a shade of grey, and putting it in a style= attribute for the element. Pre-computing the values for all of them in a
Re: [whatwg] Problems with the definition of
On Jan 21, 2007, at 10:37 PM, Benjamin Hawkes-Lewis wrote: Matthew Paul Thomas wrote: I could have said "in my 24 years of reading in a wide variety of fields I have never, not once, come across a document that intentionally used italics to indicate it was quoting someone", but I was trying to be concise. What I really meant was, there is no reason for this not be a typographical form as peculiar to the web as blue underlined hyperlinks. Three reasons come to mind. First, unlike hyperlinking, citation is already widely practiced outside the Web. Hyperlinking could be blue and underlined because it was something new to most people (except those exposed to Windows 3.x's help system, but that also used underlining anyway). Citation is not something new, and there is no obvious reason for styling it differently on the Web. Second, as I demonstrated earlier, there is no clear boundary to decide whether you are actually citing a particular person, or just mentioning them. And third, there is no benefit for the reader. It doesn't really make the text any easier to understand; and if the author's name is followed by a title that is also in italics, it may actually be harder to see which is the author and which is the work. There are even situations where this would be appropriate in modern English, which seems to be your frame of reference here. For example, when cited as the source of a quotation from a transcript in British legal writing: "Counsel's name should appear in upper-and lower-case italics" (Oxford Guide to Style (ISBN 0-19-869175-0), 423). If counsel themselves quotes someone else, does the transcript italicize the name of that someone else? Seems to be only counsel. Judges get small caps. Why this formatting applies only when quoting them, I don't claim to understand. Most likely because it's a transcript. :-) Similarly, American court documents use capitals for whoever's speaking. Hansard uses bold. ... Well, web authors' errors are understandable because the HTML references they learn from are themselves misleading. Since there is literally no form of semantic markup that HTML references are not capable of misdescribing, the implication seems to be that semantic markup is /never/ useful. And as most of HTML is semantic markup, HTML doesn't sound very useful ... ... The genius of HTML is that it gets authors to use many elements that are simultaneously presentational *and* semantic. Useful to readers *and* computers. Cheers -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] and
On Jan 11, 2007, at 7:01 AM, Sander Tekelenburg wrote: 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? Yes, where what the previous version did = nothing. ... 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. You may be right. ... 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. Good luck convincing people that their browser is lousy because it doesn't present citations. I expect the typical response would be "Eh?" 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. Ah, but we already have a thoroughly compatible element for conditional presentation of information: . So a backward-compatible way of citing sources would be an attribute that points to either (if the full citation should be out of the flow of text), or to another element (if it should be inline). For example: http://example.com/2007/01/21/c";>Fred Mondegreen concurs: When you compare it with books, the Web is still a newborn baby. As Albert Einstein said during an interview in 1949: I do not know how the Third World War will be fought, but I can tell you what they will use in the Fourth — rocks! (Disclaimer: I don't expect people would actually use this, unless there was some famous semantic application taking advantage of it. The same applies to cite=.) ... And third, it requires the existence of an IRI of some sort. Often you won't have this, for example when the source information for your quote is something as vague as "attributed to Mark Twain". I think that in such a case it would be appropriate to have the cite attribute's content point to the source that attributes it to Twain, like so: To be, or not to be, as Mark Twain supposedly said. Google notwithstanding, the Web does not contain all quotable material that exists. If the source is a pamphlet, magazine, user manual, or interview, there may well be *no* relevant URL to cite. Cheers -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] Problems with the definition of
On Jan 17, 2007, at 12:46 AM, Benjamin Hawkes-Lewis wrote:
Matthew Paul Thomas wrote:
...
This is the correct way to do it:
This is correct!, said Ian.
Despite this being consistent with the example given in the HTML 4
specification, it is not compatible with the Web (except for the tiny
part of it found on diveintomark.org and its imitators). All noticable
graphical browsers default to cite {font-style: italic}, and it is
inappropriate to italicize someone's name just because you're quoting
them.
Says who?
I could have said "in my 24 years of reading in a wide variety of
fields I have never, not once, come across a document that
intentionally used italics to indicate it was quoting someone", but I
was trying to be concise.
There are even situations where this would be appropriate in
modern English, which seems to be your frame of reference here. For
example, when cited as the source of a quotation from a transcript in
British legal writing: "Counsel's name should appear in upper-and
lower-case italics" (Oxford Guide to Style (ISBN 0-19-869175-0), 423).
If counsel themselves quotes someone else, does the transcript
italicize the name of that someone else?
I think what you're describing is a transcript, which should use
(wherein you can style to be italic), not .
Therefore, that's not what Web authors
Notorious for their understandable errors.
Which is relevant, because semantic markup is useful to the extent that
Web authors don't make errors using it.
-- or even HTML reference authors
Justly notorious for promoting such mistakes through misinformation.
Ditto.
-- understand to be for.
<http://htmlhelp.com/reference/html40/phrase/cite.html>
<http://webdesign.about.com/od/htmltags/p/bltags_cite.htm>
<http://urlx.org/microsoft.com/eec70>
Sorry, I can't take MSDN seriously. They don't even correct clear
errors when informed about them (and I /have/ told them about this
one):
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=745161&SiteID=1
Good for you, but did you really expect Microsoft to make changes that
reflect the behavior of neither their own browser nor (in the case of
) anyone else's?
If MSDN is supposed to be the measure for HTML5, we might as well pack
it in, since they'll misrepresent whatever the spec says anyhow. Also,
I think you're being unfair to htmlhelp.com, who say:
The CITE element is used to markup citations, such as titles of
magazines or newspapers, ship names, references to other sources, and
quotation attributions. Visual browsers typically render CITE as
italic text, but authors can suggest a rendering using style sheets.
This description is /entirely/ compatible with the usage under
discussion ("quotation attributions").
Quotable ships? Whatever next?
...
I think a more compatible and visually obvious (if less semantically
obvious) definition of is marking up the name of a work: a
book, film, exhibition, game, etc.
You're arguing for changing the semantic meaning of an HTML element
based on a set of modern English typographic conventions about the
formatting of citations. This line of argument is self-contradictory
because
(1) Modern English typographic conventions are crystal clear that the
entire reference is the citation, /not/ just or even especially the
italicized part.
Yes, it would be more precise if the element was called -- but
also more ambiguous, and much less backward-compatible.
(2) Modern English typographic conventions do not always use italics
for the name of a work. For example, by the Oxford Guide to Style
(ISBN
0-19-869175-0), the titles of articles, orations, unpublished works,
treaties, parliamentary statutes (and in British legal writing, even US
statutes), European secondary legislation, books of the Bible
and /suwar/ of the Koran, and rabbinical works that have become
nicknames (on this, see p. 541) are not italicized, and those of poems
frequently are not.
Yep. And if that issue, and the others you listed, prevent the
redefinition, I think the next best solution would be to drop
entirely. If a semantic element is needed for citations, introduce a
element that legacy browsers won't italicize.
Cheers
--
Matthew Paul Thomas
http://mpt.net.nz/
Re: [whatwg] contenteditable, and
On Jan 12, 2007, at 5:23 AM, Henri Sivonen wrote: ... The introduction of and (circa 1993) has failed to achieve a semantic improvement over and , because prominent tools such as Dreamweaver, Tidy, IE and Opera as well as simplified well-intentioned advocacy treat and merely as more fashionable alternatives to and . (I mean failure in terms of what meaning a markup consumer can extract from the real Web without a private agreement with the producer of a given Web page. I don't mean the ability of authors to write style sheets for their own markup.) ... Is the effort to get people to use CSS instead of spacer GIFs a bad idea? Is the effort to get people to use .. instead of or a bad idea? Is the effort to get people to use CSS instead of for layout a bad idea? There were, I'm sure, many more occurrences of those problems than there were improper uses of and . And the efforts to replace them are much older than the effort to get people who don't think about semantics to use and , which has hardly even started yet. Ten years ago, the typical Web developer probably didn't know what and were. Now, the typical Web developer probably thinks that and are dirty and that XHTML is the future. This does not mean all is lost, it just means the standards advocates oversteered. Time for another adjustment. ... Insisting on the difference of and is not without harm, because arguing about which one to use is not without opportunity cost. ... "Not without" makes that statement look more profound than it is. -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] contenteditable, and
On Jan 11, 2007, at 2:17 AM, Henri Sivonen wrote: On Jan 10, 2007, at 13:26, Matthew Paul Thomas wrote: The message "please use and unless you really know what you're doing, and generate and unless your users really know what they're doing" is *not* well-known. What's the expected payoff if the message is made well-known? As far as I know: * Better intonation for screenreaders. * Better heuristics for Google Glossary. (Continuing my example from last month, whereas "foo: bar" is likely a definition, "foo: bar" probably isn't. I'm not *sure* that this is how Google Glossary works, but for example, all its misdefinitions of the words "update" and "warning" are from , not .) * Easier styling for Chinese text. I didn't know about the last one until yesterday, so I would not be surprised if there were others. It has not yet consumed much time, effort, money, blog posts, spec examples or discussion threads. In the absence of other evidence, I think it is worth trying. In that case, I suggest making the content models for and equally versatile as the content models for and . Otherwise, authors and tool vendors will go with the elements with the more versatile content models just in case the versatility is ever needed. ... Agreed. I also suggest that the first sentence of the usage notes for and be toned down a bit, like this: "The b element should be used when an author cannot find a more appropriate element, and should be generated by authoring tools where users are unlikely to choose a more appropriate element". -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] contenteditable, and
On Jan 10, 2007, at 9:31 PM, Henri Sivonen wrote: On Jan 9, 2007, at 23:29, Benjamin Hawkes-Lewis wrote: Henri Sivonen wrote: ... and are both primarily used to achieve bold rendering on the visual media. Regardless of which tags authors type or which tags their editor shortcuts produce, authors tend to think in terms of encoding italicizing and bolding instead of knowingly articulating their profound motivation for using italics or bold. Yes, it's a bad habit picked up from WYSIWIG word processing. If people were still habituated to typewriters you'd be insisting on the intrinsic utility of . ;) Robin Williams' /The Mac is not a typewriter/ -- which, if I recall, advises against underlining -- was first published in 1990 and is still in print. Probably the underlining of links quelled underlining for emphasis on the Web. More to the point, there is utility in being able to typeset a word or two differently in a paragraph. In theory, that's . But in practice the choice between and is motivated by the default visual rendering. I don't think there's anything wrong with that, in itself. It's shorter than and . :-) ... , , and have all been in HTML for over a decade. I think that’s long enough to see what happens in the wild. I think it is time to give up and admit that there are two pairs of visually- oriented synonyms instead of putting more time, effort, money, blog posts, spec examples and discussion threads into educating people about subtle differences in the hope that important benefits will be realized once people use these elements the “right” way. If we accepted that only a few people have heard about the theoretical advantages of em and strong, wouldn't that suggest that the web standards community has not done enough communicating, not that communication has been understood but ineffective because its prescriptions are somehow impractical? Perhaps, but what's the payoff of vehemently communicating more about this? Is it worth it? Would there be a different way to get the same payoff? I think the problem is not with how few people have "heard about the theoretical advanges of em and strong", but with how many have got the mistaken impression that they are replacements for and improvements on and . This is where we really need results from Google Markup Search (paging Mr Hickson): What proportion of pages use and/or , what proportion of these appear to be generated using a Wysiwyg tool, what proportion also use and/or , and can a sample of their URLs be provided for the purpose of surveying how often and are used inappropriately? The message "please use and unless you really know what you're doing, and generate and unless your users really know what they're doing" is *not* well-known. It has not yet consumed much time, effort, money, blog posts, spec examples or discussion threads. In the absence of other evidence, I think it is worth trying. There are consequences to using and instead of and . Being ambiguous, and are insufficient hooks for speech CSS styling by the author, at least not without additional classes.) and are exactly as stylable. and are also equally stylable. Benjamin's statement would have been more accurate if he'd said "for speech CSS styling by the screenreader", because a screenreader would be more likely to specify different default intonations for and than an author would. But even if there are any screenreaders yet that make such a distinction (are there any? I forget), that's a very small benefit for a very small audience. Fantasai's example of emphasis in Chinese text is much more interesting. -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] and
On Jan 7, 2007, at 7:13 AM, Sander Tekelenburg wrote: 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 and 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? ... First, it's hard for UAs to present cite= in a way that is both usable and backward compatible. (Just changing a cursor isn't discoverable enough. Putting any extra button etc in the page might mess up page layouts, though it might work if it was placed in-line at the end of the quote.) 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. And third, it requires the existence of an IRI of some sort. Often you won't have this, for example when the source information for your quote is something as vague as "attributed to Mark Twain". (None of this is new, just a summary of what I understand from the discussion so far. I'm still thinking about alternative markup.:-) Cheers -- Matthew Paul Thomas http://mpt.net.nz/
[whatwg] Problems with the definition of
On Jan 6, 2007, at 12:18 PM, fantasai wrote:
Anne van Kesteren wrote:
By the way, I didn't really get the arguments about implementing a
construct like:
... ... ...
At least not for visual user agents.
I think the problem is what happens if I am, for example, writing
a 5-paragraph essay comparing two books. I use lots of quotations
from both books in the same paragraph in all five paragraphs, but
the cite information is complete (author+title) only in the first
instance, and the order if source and quotation is mixed up all
over the place. You can machine-process the simple case of one
quote, one cite, but there's no way to machine-process that without
some help.
...
Right. The description of attaching adjacent s to
and is not only a heuristic, it's a poor heuristic, because it will
fail often in those documents where and are used at
all. For example, it will fail where one element is in a
paragraph immediately between two s, when it may be the
citation of only one or neither of them.
There are other problems in WA1's current definition of
<http://www.whatwg.org/specs/web-apps/current-work/#the-cite>. It says:
This is the correct way to do it:
This is correct!, said Ian.
Despite this being consistent with the example given in the HTML 4
specification, it is not compatible with the Web (except for the tiny
part of it found on diveintomark.org and its imitators). All noticable
graphical browsers default to cite {font-style: italic}, and it is
inappropriate to italicize someone's name just because you're quoting
them. Therefore, that's not what Web authors -- or even HTML reference
authors -- understand to be for.
<http://htmlhelp.com/reference/html40/phrase/cite.html>
<http://webdesign.about.com/od/htmltags/p/bltags_cite.htm>
<http://urlx.org/microsoft.com/eec70>
(A counterexample is the Mozilla Developer Center's description of
, which uses the same example as the HTML 4 spec, but helpfully
shows how nonsensically Gecko would render it if you actually used it
that way. <http://developer.mozilla.org/en/docs/HTML:Element:cite>)
WA1 continues:
This is also wrong, because the title and the name are not
references or citations:
My favourite book is The Reality
Dysfunction by Peter F. Hamilton.
This is correct, because even though the source is not quoted,
it is cited:
According to the Wikipedia article on
HTML, HTML is defined in formal specifications
that were developed and published throughout the
1990s.
This is also incompatible with the Web, again because nobody would want
"the Wikipedia article on HTML" italicized unless they were emphasizing
it. On the other hand, if browser developers decided /en masse/ to
deitalicize by default, it would have no presentation at all, so
many fewer people would bother using it at all.
Further, it is a distinction most authors won't be able to understand.
For example, which of these paragraphs would be conformant?
My favourite book is The Reality Dysfunction by
Peter F. Hamilton, because Hamilton describes
wormholes as a way of travelling over long distances.
My favourite book is The Reality Dysfunction by
Peter F. Hamilton, because of Hamilton's
description of wormholes.
My favourite book is The Reality Dysfunction by
Peter F. Hamilton, because of Hamilton's
descriptions of various sci-fi ideas.
My favourite book is The Reality Dysfunction by
Peter F. Hamilton, because of Hamilton's
descriptiveness and imagination.
I arrived in Boston having read about half of Peter F.
Hamilton's latest book, Pandora's Star. This is a
nearly 900 page book, part one of the Commonwealth
Saga. I absolutely loved his first saga, the
Night's Dawn Trilogy. So far this book is
promising to be just as good.
Even if you can carefully make the distinction between the conformant
and non-conformant examples, most authors will not. It is not
plausible, for example, that an author will realize "oh, I'm no longer
actually mentioning any of Hamilton's ideas from that *particular*
book, I'd better remove the invisible element around its title".
I think a more compatible and visually obvious (if less semantically
obvious) definition of is marking up the name of a work: a book,
film, exhibition, game, etc.
To close on a minor point: en-GB-hixie notwithstanding, it's
"preceded", not "preceeded". :-)
Cheers
--
Matthew Paul Thomas
http://mpt.net.nz/
[whatwg] Presentational safety valves
On Dec 28, 2006, at 1:58 PM, James Graham wrote: Mike Schinkel wrote: Matthew Paul Thomas wrote: ... Non-heuristic machine consumption fails when semantic elements are abused, and becomes practical when elements have multiple popular meanings (examples of the latter include in HTML 4, and in HTML 5). Heuristic machine consumption fails occasionally by the very nature of heuristics (examples currently include <http://www.google.com/search?q=define:author> and <http://www.google.com/search?q=define:editor>.) The origin of this thread was my request for adding attributes to all elements to support microformat-like semantic markup. Based on the context of your reply, it seems you are agreeing with Matthew Raymond in his assertion that using microformat-like semantic markup is A Bad Thing(tm). Am I understanding your position correctly? (If I'm not, please forgive me.) Actually, IMHO mpt's point is far broader and consequentially more important than the confines of the original thread. Broader, yes (and I should have changed the Subject). I don't know about more important, because I have no experience in "microformat-like markup", and I have no idea how important it will be. So I wasn't commenting on it at all (though Matthew Raymond's arguments seem cogent). The point, as I understand it, is that machine analysis of "semantic" markup fails if the markup construct is (ab)used in so many different ways that the interpretation of any particular fragment is no longer unambiguous. This is a sort of "heat[1] death" of the original semantics; as the use of an element becomes increasingly disordered (i.e. higher entropy), it becomes impossible to extract any useful information from the use of that element. This is critical in the proper design of semantic markup languages because one wishes to stave off the heat death as long as possible so that, as far as possible, UAs can perform useful functions based on the information in the markup (e.g. render it to a media for which the content was not explicitly designed). Obviously I don't know how to achieve this but there are a few things to consider: * Have enough elements. ... * Don't have too many elements: ... * Make the semantics of elements well defined: ... * Have some "high entropy" elements. ... * Allow easy extensions. ... I think this is exactly right. Another point I would add is "implement the semantic benefit early and often". The earlier and more widely software is distributed that takes advantage of the semantics, the more easily people can see whether they are using semantic markup appropriately. I hinted at this earlier when I said that whether becomes a semantic element "will depend on who is faster: UA vendors distributing software that prominently takes advantage of the structure is supposed to provide, or eager tech Weblog authors misguidedly replacing all the occurrences of with in their templates in an attempt to be 'more semantic'." <http://urlx.org/dreamhost.com/a73e1> The "Don't have too many elements" guideline bears on Joe Clark's complaint that "'HTML5' replicates HTML's obsession with computer-science and math elements" <http://blog.fawny.org/2006/10/28/tbl-html>. It is true that HTML's few semantic elements are biased toward computer science (but not math), but that's because computer-science people are those most likely to bother with semantic markup at all (Joe being a notable exception). And adding representative elements from other fields of endeavor would likely result in too many elements overall. This post was brought to you by the society for dodgy physical analogies concocted in the middle of the night. ... As another analogy, in a recent message to Ian I referred to such presentational elements as "safety valves". Whenever someone uses , don't say "alas, that's a hole in HTML"; say "hooray, that's someone who isn't misusing ". -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] Semantic styling languages in the guise of HTML attributes.
On Dec 26, 2006, at 1:50 AM, Matthew Paul Thomas wrote: ... Non-heuristic machine consumption fails when semantic elements are abused, and becomes practical when elements have multiple popular meanings (examples of the latter include in HTML 4, and in HTML 5). That should have been "becomes IMpractical when elements have multiple popular meanings". Sorry for any confusion. -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] Semantic styling languages in the guise of HTML attributes.
On Dec 22, 2006, at 3:23 AM, Benjamin Hawkes-Lewis wrote: Henri Sivonen wrote: ... Also, it seems to me that the usefulness of non-heuristic machine consumption of semantic roles of things like dialogs, names of vessels, biological taxonomical names, quotations, etc. has been vastly exaggerated. I'm not entirely sure what "non-heuristic machine consumption" is, An example of non-heuristic machine consumption is where Google Glossary thinks: "In an HTML 3.2 or earlier document containing the code 'foo bar', 'bar' is a definition of 'foo'". (It probably thinks the same about HTML 4 documents, too, which is applying a small "ignore that nonsense about dialogues" heuristic.) An example of heuristic machine consumption is where Google Glossary thinks: "In an HTML document containing the code 'foo: bar', 'bar' is probably a definition of 'foo', especially if the page has several consecutive paragraphs with that structure and different bold text." Non-heuristic machine consumption fails when semantic elements are abused, and becomes practical when elements have multiple popular meanings (examples of the latter include in HTML 4, and in HTML 5). Heuristic machine consumption fails occasionally by the very nature of heuristics (examples currently include <http://www.google.com/search?q=define:author> and <http://www.google.com/search?q=define:editor>.) -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] several messages about XML syntax and HTML5
On Dec 19, 2006, at 9:54 AM, Benjamin Hawkes-Lewis wrote: Aankhen wrote: "I was gonna go to this site I found on Google, but then I saw that it was corrupted, so I figured it musta been a security issue or something." The original problem I was contesting and attempting to solve was that users would think, incorrectly, that such messages indicated a problem with Google. You seem to think users would think, correctly, that there is a problem with the linked page. That's what they should think, because that's what the message means. ... Alas, as amusing as this discussion is, it's not relevant to the WhatWG (and I apologize for participating). If you think search engine result pages would be better if festooned with useless warnings, lobby your favorite search engine vendor, or go start your own. -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] several messages about XML syntax and HTML5
On Dec 5, 2006, at 12:14 AM, Mike Schinkel wrote: ... [proposal for search engines to denote pages that don't validate as "HTML (WARNING)" or "XHTML (WARNING)"] I have huge doubts that this would pass even elementary usability testing, because most users would just say "I don't care". But that's the thing; usability wouldn't matter; let users ignore it. Humans don't work that way. If the words "HTML (WARNING)" or "XHTML (WARNING)" started appearing next to over 90 percent of search results, people would not think that something was wrong with 90 percent of Web pages. They would think that something was wrong with the search engine. And they would be right. -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] Allow trailing slash in always-empty HTML5 elements?
On Dec 7, 2006, at 7:47 PM, Alexey Feldgendler wrote: On Thu, 07 Dec 2006 05:09:44 +0600, Mike Schinkel <[EMAIL PROTECTED]> wrote: And if these corporations were using content management systems that didn't produce standards-based code, you can bet those CMS vendors would soon have a new #1 priority, but fast. And THAT would clean up the web quicker than any academic or grass roots effort ever could. ... As I don't work for Google, I'm not in the right position to say what is appropriate for Google to do and what is not. And I'm almost sure Hixie is not in that position eiter. Personally, I would *love* Google to do this sort of thing. I just have no hope for it. ... <http://labs.google.com/accessible/> -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] Allow trailing slash in always-empty HTML5 elements?
On Dec 4, 2006, at 6:56 AM, Shadow2531 wrote: ... Firefox could do the same with the yellow bar that pops up at the top of the page that says, "The document appears to be XHTML, but is not well formed. Firefox has reparsed it as HTML for you in an attempt to handle the errors.", or something like that. To get an idea of how this would appear to the average human: "The document appears to be XZPQR, but is not fizzlebopped. Firefox has rewotsited it as ZPQR in an attempt to handle mysterious errors". ... Sites could have a "Our pages support 'text/html as XML' handling. Add us to your browsers's text/html -> XML list.". ... That would be even worse. -- Matthew Paul Thomas http://mpt.net.nz/
[whatwg] Meaning of the title= attribute
On Nov 27, 2006, at 2:26 PM, Matthew Raymond wrote:
Alexey Feldgendler wrote:
...
In your opinion, if %Text attributes ("title", "alt") in HTML allowed
nested markup somehow, wouldn't the "title" attribute sufficient for
fulfilling the use case of captions?
No, because a caption is not necessarily "advisory information"[1],
which is what the |title| attribute is defined as containing.
...
As in, ? Eh, that's not really what title= is for.
title= is for "please use this for tooltips so alt= isn't ruined". :-)
A useful medium-independent description of title= might be
"Supplemental text that is relevant only when concentrating on the
element to which it applies".
--
Matthew Paul Thomas
http://mpt.net.nz/
Re: [whatwg] The IMG element, proposing a CAPTION attribute
On Nov 13, 2006, at 7:43 PM, Alexey Feldgendler wrote: ... I believe HTML should have an element for every attribute intended to hold human-readable text. A raw idea can go like this: ... Here, holds a value which should be treated the same way like the title attribute on , except that it can contain nested markup. This would be useful for all attributes defined as %Text in HTML -- in HTML4, these are ABBR, ALT, LABEL, STANDBY, SUMMARY, TITLE. ... You would need to stipulate that title= couldn't contain any elements. A link in a tooltip would usually be impossible to click. :-) -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] The IMG element, proposing a CAPTION attribute
On Nov 9, 2006, at 11:57 AM, Jeff Seager wrote: ... Among all literate people, I believe there is a longstanding expectation that pictures are accompanied by meaningful descriptions (usually below the image, but often to one side). The absence of image captioning seems to me to be an oversight, or at least an overlooked possibility, in the HTML/XHTML standards. As I was taught, a proper caption should not describe the picture (as ALT should), but complement or elucidate the information presented by the graphic. alt= should not describe a picture, but rather be a text alternative, because a description is a non-sequitur in a non-visual medium. (Unless, perhaps, the UA precedes it with the phrase "And if you weren't so blind you could see an image here that shows...":-) Anyway, I support the idea of a caption *element* to accompany images. This would have two benefits over an attribute: 1. It could contain markup, which an attribute cannot. 2. With a for= attribute, it could apply to an image elsewhere in the document, which would be useful for the print medium. For example: Top left: The class of 2006. Top right: Simone with her parents on graduation day. (For the screen medium, ideally UAs would place a caption adjacent to the relevant image, regardless of where the caption occurred in the document.) I suggest that this element behave in the opposite way from alt=: whereas alt= should be presented only if the image itself is *not* presented, the caption element should be presented only if the image itself *is* presented. Otherwise there would be the same problem with non-sequiturs in non-visual media as there is with descriptive alt=. -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] element comments
[re. width= and height=] On Nov 4, 2006, at 9:01 AM, Alexey Feldgendler wrote: On Sat, 04 Nov 2006 12:37:32 +0600, Ian Hickson <[EMAIL PROTECTED]> wrote: ... I'm thinking of only allowing integer values, and requiring them to be equal to the dimensions of the image, if present (and requiring both to be present if either is present). Would people be ok with that? ... That's how these attributes could have been defined if we were designing HTML from scratch. In today's browsers, specifying width and height on different from the actual dimensions of the image forces the image to be resized for display. There is existing content which relies on this. ... In 1998 I used a version of iBrowse for the Amiga that treated width= and height= in the way Ian proposed -- as preliminary advice on the dimensions of the image, reflowing if the actual dimensions turned out to be different. It often produced amusing results, as images popped into sizes far larger than the ones the page had asked for. This situation may have improved with the development of the Web design industry since 1998. But I still occasionally come across photo galleries, in particular, that use width= and height= as a (very slow) alternative to thumbnails. It may be possible to use the Google Images corpus to find out just how common this problem is. -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] colspan="0"
On Nov 4, 2006, at 1:53 AM, Henri Sivonen wrote: None of Opera 9.02, Firefox 2.0, IE7 and Safari 2.0.4 implement colspan="0" as specified in HTML 4.01. Trident, Presto and WebKit at least agree on what to do with it: they treat it like colspan="1". I suggest that only positive integers be conforming and that non-conforming values be treated as 1. ... I know browser vendors have had a long time to implement this, but still, I think giving up on it would be a shame. The number of rows or columns in a table is often rather expensive to calculate ahead of time. As long as this has to be done to calculate the rowspan= or colspan= of header cells, this can substantially increase the time an application takes to generate a table. For the browser to interpret colspan="0" or rowspan="0" instead would both make life easier for application authors, and make such pages faster overall. -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] Footnotes, endnotes, sidenotes
On Oct 31, 2006, at 7:57 AM, Alexey Feldgendler wrote: On Tue, 31 Oct 2006 21:54:12 +0600, David Walbert <[EMAIL PROTECTED]> wrote: ... I would never want to require that a footnote be read to anyone, thereby interrupting the text -- it is in the nature of a footnote to be optional reading and to stand apart from the text. Any user should have the option of reading/hearing it, or not. But how would the user know that there is a footnote anchored to a specific place? ... By a variation on the way the screenreader tells them there is a link anchored to a specific place. For example, an unobtrusive sound effect at each footnote reference, and a command to read the last-encountered footnote. -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] [HTML5] Editorial: 3.10.18. The |sup| and |sub| elements
On Nov 1, 2006, at 1:32 PM, Christoph Päper wrote: The second to last example should probably better read: E = m · c2 or maybe, as the speed of light is a constant, E = m · c2. ... Is that equation ever legitimately rendered (in physics textbooks etc) with the "m" in a different style from the "c"? If not, perhaps the definition of needs to be expanded to include physical constants. -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] caption (was: How not to fix HTML)
On Nov 1, 2006, at 7:50 PM, Michel Fortin wrote: Le 1 nov. 2006 à 22:01, Jonathan Worent a écrit : ... or make the association implicit by using the for attribute A funny video of a man being hit in the groin by a football That would work for the current page layouts of YouTube and Google Video. I think what would work best for this is the element I've proposed back in june: Some caption here ... ... That would not. (At least, not without some tricky CSS.) -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] Footnotes, endnotes, sidenotes
On Oct 31, 2006, at 7:20 AM, David Walbert wrote: ... Footnotes and endnotes are identical in content in the context of a print document and I am not certain how they'd differ even presentationally on a web page, so yes, I think those can be considered identical in terms of markup. ... Scholarly books sometimes use both footnotes and endnotes for different things -- footnotes for citations and endnotes for tangential discussions, or vice versa. I've never seen an HTML document try to make this distinction, though. -- Matthew Paul Thomas http://mpt.net.nz/
[whatwg] The utility function for semantics in HTML
On Nov 1, 2006, at 11:55 AM, James Graham wrote: ... To take a slight detour into the (hopefully not too) abstract, what do people think the fundamental point of semantics in HTML is? To maximize the utility (usefulness) of documents using it. But this is a complicated function. * Less presentational -> more medium-independent -> accessible to more people -> greater utility. (Examples: people using screenreaders or search engines.) * More semantic -> harder to learn and understand -> fewer documents using it -> less utility. (Example: DocBook.) * More semantic -> harder to learn -> simpler alternatives invented -> learning and/or transcoding-to-HTML effort required -> less utility. (Examples: Markdown, BBCode, the various partly-incompatible wiki syntaxes, and any Web comment form that allows -- or doesn't convey whether it allows -- a subset of HTML.) * More semantic -> more machine-analyzable -> greater utility. (Examples: Google's PageRank with , Google Sets with .) * Less presentational -> more semantically-misused -> less machine-analyzable -> less utility. (Example: XHTML2's attempt to kill and , resulting in more misuse of and .) Many people concentrate on one or two of these effects and gloss over the others, so their idea of the overall utility function is warped. -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] [HTML5] 3.10.9. The |abbr| element
On Nov 2, 2006, at 3:44 PM, Jonathan Worent wrote: --- Christoph Päper <[EMAIL PROTECTED]> wrote: First off I think the requirement for a |title| is too strict, because there are time and space saving abbreviations everyone knows -- i.e. either their expansion or their meaning -- that do not need an expansion, e.g. "e.g." or "AIDS". Therefore the second sentence should use 'may', not 'should'. Agreed. (At the least, the specification is currently ambiguous about whether title= is required.) I disagree. There is never a guarantee that people will know what an abbreviation stands for, I know what AIDS is but not what it stands for. But that applies not just to abbreviations, but to writing in general. All writing assumes a level of knowledge. If a blind biologist listening to a scientific journal heard "DNA" expanded as "deoxyribonucleic acid" on every page, that would quickly become infuriating, even if the UA was smart enough to do it for only the first occurrence on each page. (Temporarily turning off such expansions would be unreasonable if there were other, unfamiliar, abbreviations present; and trying to request expansions from the UA case-by-case would be tiresome.) ... i. e. This would not be correct usage because the abbreviation i.e. does not represent "that is" it means that though. In this case you using is to mark up the definition. I use i.e. not just because that's what it means, but because that's how it *should* be expanded if it needs to be expanded, for example if it is being read aloud. (Expanding it as "id est" would be pretentiously unreasonable.) Similarly in "Mac OS X", I don't give "OS" a title=, because what "OS" stands for is never relevant in the context. -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] [WebForms2] custom form validation notifications
On Oct 4, 2006, at 4:05 PM, Brad Fults wrote: On 10/3/06, Joao Eiras <[EMAIL PROTECTED]> wrote: ... If the user fills a form in an improper way the UA should alert him of the problems. Opera in the early days of its initial web forms support showed an alert box stating that the information was invalid, now it flashes the input field, and presents a message overlapped in the webpage. However it presents a very generic error message like "You must set a value!" (for required) or "foo is not in the format this page requires" (for pattern). The author may want, in the case of an error, to present its custom error message to the end user. This could be achieved by declaring new custom attribute for the several controls, which could hold the message. The UA could then either pop up that message to the user or embed it in the page (like Opera does currently). The attribute could be named like requirederr, patternerr, or use some other sort of naming convention to easily associate the constraining property with the message attribute. As UAs become more sophisticated, they can analyze the pattern attribute and present more context-sensitive error messages than any such attribute could. For example: * "410 is too much; this number must be 300 or less." * "178 is too small; this number must be 200 or more." * "This field must start with a letter." UAs can also localize these error messages much more extensively than any Web site could (which will be even more of a benefit when the Web site is not in your preferred language). Is the use of the title attribute inappropriate for this case? ... It has the same lack of context. -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] input type="country"?
On Aug 23, 2006, at 5:08 PM, Dean Edwards wrote: On 23/08/06, Arve Bersvendsen <[EMAIL PROTECTED]> wrote: On Wed, 23 Aug 2006 16:02:24 +0200, Martijn ... I'm sure there is an official list out there (United Nations?), with all the countries in the world. What happens when a web developer lives in a part of the world doesn't agree with the 'official' list of countries? You use a . ... Or, if you're using Web Forms 2 anyway, a . -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] Where did the "rev" attribute go?
On Jul 13, 2006, at 2:57 AM, Robin Lionheart wrote:
...
Do the benefits of the computer having such knowledge outweigh the
cost of the human labor required to mark up names?
Good question. I expect many Web authors would not avail themselves of
the option of using even if it were available.
...
Indeed, because it wouldn't offer them any presentational benefit
(except in the sort of gossip columns that have name {font-weight:
bold}).
Perhaps someone could ransack the W3C mailing list archives and find
out why all the new inline semantic elements in the HTML 3.0 draft
survived (with minor modifications) to HTML 4, *except for*
and [thor]. <http://www.w3.org/MarkUp/html3/logical.html>
--
Matthew Paul Thomas
http://mpt.net.nz/
Re: [whatwg] Spellchecking proposal #2
On Jun 25, 2006, at 11:59 PM, Lachlan Hunt wrote: Matthew Paul Thomas wrote: ... But realistically, browsers won't "allow the user to easily override it if they want to", because any interface for doing that would be absurd. ... * Status bar icon/text that indicates if spell checking is on or off, and if on, whether or not there are any errors (similar to that found in Microsoft Word). * Toolbar button used to toggle spell checking on or off and indicate it's state. * Context menu item (Opera already has this) * Floating toolbar that displays (possibly docked to one side of the text area) when the textarea has focus, with buttons for things like: spell checking, find and replace, cut, copy, paste, etc. Okay, I should have said "any interface for doing that will be either absurd, or so invisible as to make the feature seem like random flakiness". Though commendable, your first and third suggestions are the latter; your second and fourth, and Alexey's attempt, the former. I'm sure there are other people that know a lot more about UI design than I do, who could come up with some really creative and usable. The problem is not with which GUI controls you choose; it's with the amount of attention demanded by the underlying situation. Spellchecking would seemingly be turning itself off for a completely non-obvious reason; and to make it obvious, you would have to make the spellchecking feature more prominent than its importance permits. Perhaps a useful analogy: HTML5 is about making Web applications easier, and in Web applications dataloss often results from going back to previous pages, so there should be a backbuttonallowed= attribute that can be set to "false" for the element. And we'll let the user easily override it if they want to. -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] Spellchecking proposal #2
On Jun 25, 2006, at 2:02 AM, Lachlan Hunt wrote: ... However, the proposed spellcheck attribute has one major advantage over all of those: it's being designed to allow the user to easily override it if they want to. But realistically, browsers won't "allow the user to easily override it if they want to", because any interface for doing that would be absurd. For example, in Opera: | Select all #A | || | Check spelling| | Really check spelling | || Teehee. Or in Safari (where the spellchecking interface is confusing enough already, thanks): |-| | Find >| |::Spelling::>| Spelling… #: | | Check Spelling #; | |/ Check Spelling as You Type| || |/ Spellcheck Sometimes | |__Spellcheck Always_| Firefox doesn't seem to have a design for spellchecking published on their Web site yet. Maybe, if they're going to support a new attribute for authors to influence spellchecking, they'll expose it in the Preferences dialog: [/] Check my spelling in Web page forms [ ] Even if the page author disagrees ... Yeah, right. Bottom line, browser vendors will either ignore the attribute, or they'll make it configurable in a really obscure place (about:config or equivalent), and leave 99.9% of people wondering vaguely why spellchecking works on some pages and not others. -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] On accessibility
On Jun 14, 2006, at 9:47 PM, Alexey Feldgendler wrote: On Thu, 15 Jun 2006 08:09:43 +0700, Lachlan Hunt <[EMAIL PROTECTED]> wrote: Accesskey implementations need to be seriously improved if they are to be retained. There's significant evidence to show that there are very few, if any, safe keys available which don't clash with existing shortcut keys in browsers. What Opera does makes sense. Maybe it should be standardized. ... What Opera does is indeed very cool, but it's quite possible that another browser could come up with something even cooler. And in this area there is very little benefit from interoperability, so I don't see any point in standardizing it. It would be like standardizing on vi. (Or emacs.) (There is actually *harm* from interoperability for accesskey=, from Web authors cluttering pages with instructions on how to use access keys because they're so non-obvious -- instructions that may be incorrect for some platforms, depending on how they're worded, and that are irrelevant for non-interactive UAs like Google.) -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] Show upload progress
On May 6, 2006, at 7:41 PM, Joaquin Cuenca Abela wrote: Matthew wrote: A much easier and more consistent approach would be for the browser to show the upload progress itself. Complain to your friendly local browser vendor. Unfortunately such a simple approach is not good enough in this case. The progress bar in a browser is "optimized" for small - medium file uploads: no estimated time left, quite small, on a blind corner, assumes the size of the downloaded page is somewhat in the range of the size of the file uploaded, so it's estimation of % done is wildly pessimist. I have yet to see a browser that shows determinate upload progress at all. (Internet Explorer, Firefox, Safari, Opera, and iCab all don't.) But it should be easier to implement than showing determinate download progress, because with uploading the browser knows ahead of time exactly how much data is involved. That's why I'm suggesting you lobby browser vendors to implement it: not because they already do, but because they don't. (You may be under the impression that Internet Explorer for Windows shows determinate upload progress. But its progress meter actually advances 1 pixel/second starting from the beginning of the request, regardless of the progress of any upload. So if it has taken longer than 90 seconds, the progress meter reaches 100% and gets stuck there.) ... 1) the file the user is going to upload is expected to be > 0.5M 2) once uploaded, the html with the response is extremelly small compared to the file(s) uploaded In that use-case you want a bigger progress bar, on a very visible spot on the page, and giving the user a clue of the time remaining. Sure. But again, it would be much easier and more consistent if the browser showed a bigger progress bar, overlayed on the page, with an estimate of time remaining, for *all* uploads likely to take more than about 5 seconds -- rather than some Web sites doing it and most not. ... Oh, and to add another item to the previous list: * There is only one progress bar in the browser. The thing is you may have the main upload going targetting a frame, and have some xmlhttprequest / iframe downloads going on the background. It will drive crazy the browser progress bar. Only the page author knows what's the most probable big, blocking upload/download in the page. ... I don't think that's true. Browsers (other than Opera) already handle the problem of presenting progress of multiple items in a single progress bar when downloading a page. They could do an even better job for uploads, since they know the size of the items involved beforehand. And good results probably would be achieved from ignoring XmlHttp traffic for progress bar purposes whenever displaying any non-XmlHttp progress. -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] Show upload progress
On May 6, 2006, at 9:50 AM, Joaquin Cuenca Abela wrote: ... A lot of people are implementing progress bars that show in real time the upload status of files being uploaded. Right now it's a pain to implement that kind of functionality, as the browser has to poll regularly the server with a secondary connection to get the total size of the request, and the number of bytes already received. Given that the browser already knows that information, I think it would be great if it could expose it on some DOM object. What do you think? ... A much easier and more consistent approach would be for the browser to show the upload progress itself. Complain to your friendly local browser vendor. -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] Select conformance
On Apr 1, 2006, at 11:04 PM, Henri Sivonen wrote: On Mar 30, 2006, at 06:56, Alexey Feldgendler wrote: ... I think it should be allowed. It's useful for dummy items like "Select your country" which is pre-selected in the dropdown with the list of countries. Whoa! It's even interoperably supported in Firefox and Opera. http://hsivonen.iki.fi/test/wa10/adhoc/option-selected-disabled.html It still does not make it good UI. The case is similar to a set of radio buttons with no checked button. ... Actually, it's worse than that. In some themes, the only way you can see that a control is disabled is that its contents are greyed out -- its outline does not change. (This is true of buttons in the Classic theme in Windows, for example.) So a whose selected item (and therefore its only visible item) was disabled would look entirely unusable. -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] Select conformance
On Mar 30, 2006, at 6:15 AM, Henri Sivonen wrote: Single select: Is it conforming for an option to be both selected and disabled? (I think it shouldn't be conforming.) Agreed. If you're not permitted to choose, the whole should be disabled. And analogously: Is is conforming for a radio button to be both checked and disabled if the whole set is not disabled? (This one is harder to check, but anyway...) I think it shouldn't be, for the same reason. Is it conforming to have no option that is marked selected? (I think allowing this is safe.) I'm pretty sure we've been through this before -- I think it shouldn't be, ratemy*.com thinks it should be, and there are more of those sites than there are of me. :-) (Why they don't just use a set of numbered s, which would work even with JavaScript off, I have no idea.) Select multiple: Is it conforming for an option to be both selected and disabled? How do native widgets handle this? ... I don't see why not, since it wouldn't be adding any new elements or attributes, though it wouldn't be very commonly used. Breakfast: __ |[/] Egg |A| |[/] Bacon |:| |[ ] Sausage |:| |[ ] Lobster Thermidor a Crevette|:| |: : Baked beans (currently unavailable) |:| |[ ] Tomato |:| |:/: Spam|V| """""""""""""""""""""""""""""""""""""""""" To distinguish between selected disabled and unselected disabled options, browsers would need to start including a checkbox for each item in a . But then they should have been doing that all along, both to distinguish between and size>, and to save people from having to know Ctrl+click/Command+click. -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] draft
On Mar 29, 2006, at 12:02 AM, Ric Hardacre wrote: Matthew Paul Thomas wrote: ... Sure, but they have different meanings. Progress bars are intended to reach 100% unless cancelled; vote counts are not. In Mac OS, and many Gnome and KDE themes, will have an animated appearance by default; will not. you mean the progress bars that just show a bar bouncing back and forth or scrolling across and therefore not actually showing the amount of progress? ... No, I mean all of them. For example: * <http://jimmac.musichall.cz/weblog.php/Design/Progress.php> implemented as <http://myeburg.net/home/notes/show.8.html> * <http://www.kde-look.org/content/preview.php? preview=1&id=6345&file1=6345-1.png&file2=6345-2.png&file3=6345 -3.png&name=Animated+Keramik> -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] draft
On Mar 28, 2006, at 9:05 PM, Ric Hardacre wrote: Ian Hickson wrote: ... The only difference between meter and progress is the potential for progress to be dynamic. That's a big difference. It means the UI for one has to show that it is static, and the UI for the other has to show that it should "end". which is laudable, and makes sense, but each will be updatable on the fly. a meter has to have this ability, e.g. allowing CNN to show the election votes cast on their home page, updated asynchronously. ... Sure, but they have different meanings. Progress bars are intended to reach 100% unless cancelled; vote counts are not. In Mac OS, and many Gnome and KDE themes, will have an animated appearance by default; will not. -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] A better name than for the element that shows
On Mar 21, 2006, at 6:23 AM, Ian Hickson wrote: On Tue, 21 Mar 2006, Lachlan Hunt wrote: Ian Hickson wrote: ... Unfortunately, the study Google did on Web authors showed that authors cannot spell the word "language", and I see no reason to believe that they might spell "gauge" either. But unlike the almost entirely useless "language" attribute, gauge will actually have a noticeable result in future browsers and so if it's typed incorrectly, the author would not see the result and, hopefully, go and fix it. Whereas if they mistype language, they won't notice the error until they validate. That makes it easier for them to correct it, but it doesn't make it easier for them to type it in the first place. ... Does that mean the HTML and CSS specifications are badly designed when they use the word "color"? (Or that one of the early Risc OS Web browsers was correct in recognizing the "colour" attribute as well?) Sometimes the best word for something is one that's often misspelled, and I agree with Lachlan it's not a problem in this case. People leave language= misspelled only because it has no obvious effect. With , as with "color", the result will be very obvious and the correct spelling quickly learned. -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] 2.20.2 The command element - icon attribute
On Mar 3, 2006, at 7:11 AM, ROBO Design wrote: ... <[EMAIL PROTECTED]> a écrit: On Mar 2, 2006, at 9:21 AM, ROBO Design wrote: ... I'd highly recommend not to define the icon attribute, or any other attribute with possible relation to presentation. This fuels accusations that what this specification defines is not "as semantical as" the XHTML 2 specification ... I wasn't subscribing to those opinions. I was just saying some people complain. Then why mention them at all? That seems like dog-whistling. ... I was having a quite interesting talk with a guy. I could've called him naive - he's not an expert in web development at all. He strongly disproves of not being able to style scrollbars, buttons and more. People will always want to do so. Native rendering won't suffice. Some designers hate seeing native buttons, inputs, selects and whatever. And they can continue to implement and/or style controls, and pay the cost of having less usable sites, just as they do now; with the browser vendors saving the Web authors from themselves, to the extent the people using the browsers desire, just as they do now. If the specifications won't give them the proper ways to style them, we'll see quite many annoying hacks of the future. I think the sum (annoyance ✕ popularity) of those hacks will be less than the sum (annoyance ✕ popularity) of fully stylable menus would be. You think the reverse. I think that's the real disagreement here, and we can't prove it one way or the other. Developers are making the switch to CSS layouts, departing away from table layouts. Now is the time for CSS to evolve and give them all the power they want. Non sequitur fallacy. Actually, two of them. First, that more people are using CSS does not necessarily mean CSS should "evolve and give them all the power they want". (Such a process would probably lead to something as unwieldy as XHTML 2.) Second, even if CSS should "evolve and give [developers] all the power they want", that would not necessarily mean that Do you have any specific reason for wanting of CSS? I'm not thoroughly opposed to the idea, it just seems very inconvenient. Most icons will be used for only one menu item, so the "you don't have to repeat yourself" argument for using CSS doesn't apply. In that respect it's quite similar to I wouldn't personally like seeing a new menu for each web app, but that's the way it goes. Slippery slope fallacy. Currently, Web authors who want menus in HTML either (a) misuse with script, or (b) implement their own with positioned elements and script. Introducing a third option, (c) use and related elements, won't increase the proportion of Web developers using (b)! It certainly won't result in "each Web app" using (b). Leave open doors for ugly hacks or not? False dilemma fallacy. There is no "or not": HTML 5 doesn't, and can't, prevent Web authors from continuing to use the ugly hacks they're already using (except to cry "non-conformant!" and let slip the dogs of validation). What it can, and does, do is offer better alternatives to those hacks. ... I almost can hear a web developer "ugh that's ugly!!!" (seeing the menus natively rendered). And he or she has to put up with such vomitous native controls in every menu and every dialog of Dreamweaver, too! The poor thing. ... Then do what native application developers do in the same situation, when they want to be gratuitously inconsistent with the rest of the platform: implement your own menu controls. <...> True. I myself don't like scrollbar colors being changed just because the designer of the site wanted so. It's annoying. So the anecdote of the naïve guy above was more dog-whistling? You either: agree, embrace or disagree with diversity. ... I suspect that's another false dilemma, but to be honest I'm not even sure what you're saying. :-) Cheers -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] 2.20.2 The command element - icon attribute
On Mar 2, 2006, at 9:21 AM, ROBO Design wrote: ... I'd highly recommend not to define the icon attribute, or any other attribute with possible relation to presentation. This fuels accusations that what this specification defines is not "as semantical as" the XHTML 2 specification If that's true -- and it's hard to tell, because the XHTML 2 draft is so wordy -- then HTML 5 is probably on the right track. (Even then, as I described in January, a few parts of the Web Apps draft are almost certainly too semantic for most HTML authors to follow. <http://64.233.179.104/search?q=cache:hPXm-qGuZjEJ: listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006-January/ 005431.html>) (I've read some "WHATWG bashing" in some blog posts). That's not a useful comment. What did they say? Defining icons and other presentational endeavours must definitely be left to CSS WG. Why? Lets take the icon. Designers would immediately want to define the positioning of the icon: top, right, bottom, left - in pixels, percents, etc - similar to background position. And UA vendors would be free to ignore such attempts on platforms for which such customized positioning would not make sense. Which is, all of them. Then they'll "hack" into the DOM to change the icon on hover, and do some more. That would be unfortunate, and it would be nice if UA vendors ignored attempts to do that too, though not as important. All this stuff must be defined by the CSS WG. Why? The WA 1.0 "loosely" defines the icon attribute. That's not an attribute of a semantical value, it's for a pure presentational purpose. The difference between and ... type="radio"> is purely presentational. The difference between multiple> and ... is purely presentational. The difference between and is purely presentational. That doesn't mean they shouldn't all exist. If Ian Hickson really wants to define the icon attribute in the spec, then he should go further and offer complete customization over the way the icon is rendered. Why? Native menu implementations don't. Or should the icon render as normal icons render in the default chrome of the user agent (most likely of the OS)? Naturally. If that's the case, designers won't be happy either (neither myself, being a designer too). We always like to do different designs. ... Then do what native application developers do in the same situation, when they want to be gratuitously inconsistent with the rest of the platform: implement your own menu controls. That will be more difficult than using , of course, which is good because it means authors will be more likely to use instead. -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] Definition of alt= attribute
On 24 Jan, 2006, at 5:43 AM, dolphinling wrote: Matthew Paul Thomas wrote: Bizarre but serious conclusion: alt= should be optional for in documents where a element is present. How about "Authoring tools MUST only provide alternate text that the author explicitly requests, That would seem to prevent, for example, Microsoft FrontPage from generating the obvious alt text for an Image Composer image that consisted only of text sprites. (And since Microsoft continue to misimplement the existing spec for alt=, it wouldn't be a good idea to trust them to interpret "explicitly requests" the way you want.) and especially MUST NOT provide alt="" unless the author specifically says that the alternate content is empty. Authoring tools SHOULD make it obvious to the author what the meaning of alt= is, for example with the string "What text should be used if the image cannot be displayed?"" <http://slick-net.com/space/stamps/> That example of awful alt= text was apparently made with vi. Would vi be violating your SHOULD, for not making the meaning of alt= obvious? ... Problems with this approach include the following: First, it could be interpreted as disallowing pseudo-AI. This could be fixed with a note saying "This should not be interpreted as disallowing pseudo-AI in authoring tools, but even a pseudo-intelligent authoring tool MUST NOT assume an empty alt text." I think that text fails the "wtf?" test. Does it cover the Image Composer example above? Nobody would be able to tell. Second, it could force authoring tools to produce invalid documents if the author did not provide any alt text. However, those documents would be non-conformant anyway, so this is not a huge problem. ... It would be a problem as long as "generates valid HTML" is considered a feature separate from conformance, since software can guarantee the former but not the latter. And I don't think anything in an HTML 5 spec could prevent validity from being seen as a feature. That's why I propose the exception for compulsory alt=. -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] Definition of alt= attribute
On 22 Jan, 2006, at 3:20 AM, Jonny Axelsson wrote: On Sat, 21 Jan 2006 13:54:34 +0100, James Graham <[EMAIL PROTECTED]> wrote: ... People seem to have passed this point by. the current specification of alt as required makes it almost impossible to design a conforming HTML editor that doesn't mess up the semantics of the attribute. Since many (the majority?) of HTML pages are produced using some form of graphical editor (often implemented using contentEditable or some other HTML+js solution as part of a CMS), the spec should at least consider the needs of editors as well as UAs. I don't think that can achieve anything -- ceteris paribus, a graphical editor's ease of use will be inversely proportional to how well it encourages accessible and semantic use of images, no matter how they're represented in markup. At one end of the scale, you have software where an image is inserted by dragging and dropping, and there is no interface for alt= text at all (such as most graphical mail clients). At the other end, you have a two-paned editor where the top pane shows the normal WYSIroughlyWIG presentation, and the bottom shows the page with no CSS and with editable inline alt text instead of images (nice for a dedicated Web author, but utterly unreasonable for rich-text e-mail or Web applications). In the middle, you have an 'Alt text" field buried in a dialog somewhere, with long-running disputes over how insistent it should be (as in Mozilla Composer). For those using text editors, however, there is a way of encouraging suitable fallback content: encourage use of and discourage use of . It is much more obvious that should perhaps have something inside it than that is missing an alt= attribute. And for those few who read the spec, you can define tongue-in-cheek as "a piece of text with an alternate graphical representation", as Ian has already done; and provide guidance on the use of alt=, as I did at the start of this thread. ... The danger with making an aspect of a markup language mandatory, like the mandatory 'alt' attribute for 'img' and the mandatory 'title' element in 'head' is that the editor/author will need to use filler content that may reduce the quality of the attribute/element in question. With 'alt' this has the consequence 'alt=""' means either that this image has no alternate representation (and presumably semantic content) or that it has been automatically been filled in to make the document validate. It is fairly acceptable, but it would have been better that no 'alt' attribute at all had been used in the latter case. The guess the W3C seem to have made is that the benefit from people who add alt= appropriately solely because it's a validity requirement is greater than the harm from people who add alt= inappropriately solely because it's a validity requirement. This may well be true, though a usability test of this would be fascinating. People who care about validity in the first place are more likely to care about appropriate alt= text (though they still often do a terrible job at it). However, people using graphical authoring tools are *not* likely to care about appropriate alt= text, so it is better for the Web if such tools omit alt= than if they force it to some default value to generate valid documents and avoid persecution by the Web Standards Project. Bizarre but serious conclusion: alt= should be optional for in documents where a element is present. -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] Definition of alt= attribute
On 20 Jan, 2006, at 1:18 AM, Alexey Feldgendler wrote: ... The alt attrubute should be made optional, and when it's omitted, the UA should try to obtain some useful information from the file name or by other means. ... Gecko used to do that <https://bugzilla.mozilla.org/show_bug.cgi?id=5764>, but no longer does because it didn't work for the many cases of and the like. (I can't find where the latter decision was made, but IIRC Ian Hickson was the one who made it.) -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] Definition of alt= attribute
On 19 Jan, 2006, at 1:53 AM, Lachlan Hunt wrote: Matthew Paul Thomas wrote: I can think of no reason for Ah, of course, I had forgotten about . It would have been more obvious to make alt= compulsory where type="image", and prohibited otherwise. ( Why would a form element need alternate content? ... For non-interactive UAs, rather than non-graphical ones. * * I'm not saying it's a *good* idea, just that it would have made more sense than allowing alt= for non-image s. :-) -- Matthew Paul Thomas http://mpt.net.nz/
[whatwg] Definition of alt= attribute
For a while I've been honing a clearer definition of the alt= attribute, one that tries to curtail the worst misuses of the attribute without being horribly wordy. Since alt= is not yet defined in the Web Applications 1.0 draft, my text may be useful. In HTML 4 alt= is an attribute for , , and . I can think of no reason for slightly more sense, for non-interactive UAs), and Web Applications 1.0 currently includes an "applets" HTMLCollection but no element, so I've tweaked the text to refer to elements exclusively. If is introduced, alt= should be put in a "Common attributes" section, and occurrences of "image" changed to "item". Anyway, continuing from the existing beginning of the section: Since the two representations are alternate, not supplementary, a user agent should render either an image or its alternate text but not both at once. For example, a UA should not show alternate text in a tooltip. Authors who wish to provide supplementary text for an image may use the title attribute instead. Specifying alternate text helps readers without graphic display terminals, visually impaired people, others who prefer listening to documents rather than viewing them, people viewing documents offline when an image is not available, and so on. To produce sensible alternate text, authors should follow these guidelines: Do not describe the image. For example, do not write class="bad example"><img src="logo.png" alt="ExampleCorp logo">, or <img src="logo.png" alt="logo.png (3890 bytes)">. Instead, write text that fulfils the image’s purpose; for example, <h1><img src="logo.png" alt="Welcome to ExampleCorp"><h1>. A description is appropriate only if the image itself is discussed but not elsewhere described in the document. For example: <p>I managed to snap a photo of the animal. <img src="animal.jpg" class="photo" alt="It's a bit blurry, but it shows a large brown creature running through the forest."> At last, evidence of the moa!</p> Do not provide alternate text for an image when it is used for formatting, decoration, illustration, or linking to a solely graphical resource. Instead, use alt="". For example, a portrait of someone should usually have alt="", unless either their physical appearance or the artwork itself is highly relevant and not described elsewhere in the document. -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] , , ,
On 17 Jan, 2006, at 11:21 PM, Anne van Kesteren wrote: ... You snipped the part about not being in the proposal for HTML5 which is pretty important imho. ... Either is going to be in HTML 5 but has yet to be specified (like ), or it's not going to be in HTML 5 but is incorrectly used in some examples. If the latter, that will make certain the semantic-free fates of and . -- Matthew Paul Thomas http://mpt.net.nz/
[whatwg] Presentational elements in Web Applications 1.0
On 14 Jan, 2006, at 1:24 PM, Lachlan Hunt wrote: Eugene T.S. Wong wrote: I'd like to recommend that the WHATWG bring back because it provides an excellent way of saying "this is a centered ". is no more semantic that , , or , yet they have their uses. No, center is presentational, div is not. is presentational: it means "present this as a block". That is what it will mean in HTML 5 documents as well, regardless of how it is eventually defined in the specification, because author momentum will be too great to usefully narrow its meaning. And that's okay: there is no evidence that any deity kills a kitten when someone uses . Authors should not use presentational markup, regardless of how much easier it seems. ... Authors should use presentational markup whenever there is no available semantic markup for the relevant meaning, or when they are providing authoring facilities for people who cannot be expected to think about semantic markup (e.g. people using Webmail, or people posting comments on the author's Weblog). If authors -- or specifications -- try too hard to use a semantic element, or to force other people to use it, it will be misused so much that UAs can no longer trust the element to have any particular meaning, so it will become de facto presentational. The semantics of an element come partly from its specification, and mostly from the people who use it. If the current definitions of elements in the Web Applications 1.0 draft remain as they are, and HTML 5 becomes widely used, HTML 5 documents will feature nine presentational elements. This was defined in HTML 3.0 and 3.2 to mean about the same as means in Web Applications 1.0, but was soon repurposed by Web authors for any block for which the author could not think of a better element. It will continue to be used that way in HTML 5, because even if replacement elements like , , , , , , , and were introduced in an attempt to narrow the use of , authors would hardly ever bother using such specialized elements, since they'd get no benefit from doing so. (But and will reduce the use of by a small amount, because they have distinct and useful default presentations.) , , These elements were semantic until HTML 4.0, which belied their supposed meaning both in an example in the spec, and in the markup of the spec itself. They remain presentational in the current Web Applications 1.0 draft, because use for both "terms and definitions" and "name-value data" is still too broad to have a coherent meaning. (For example, from the markup alone, a search engine will not be able to tell whether "Ian Hickson, Google, [EMAIL PROTECTED]" is the answer to "Who is the editor of Web Applications 1.0?", or a definition of the word "editor" itself.) This has always been presentational, and will continue to be so in the majority of HTML 5 documents. Most authors will assume it has the same purpose as it did in previous versions of HTML; and many of the authors who actually read that part of the spec will giggle at the "instance of a term" frippery and disregard it. This has been semantic until now, meaning a paragraph. But the current Web Applications 1.0 draft pretends that the English word "paragraph" means something much broader than it really does, so broad that it will have no semantics at all. (For example, someone instructed to write a ten-paragraph essay will get incorrect results from a paragraph count if, as suggested by Web Apps 1.0, they use for the essay's byline.) As a result, will come to mean "present this as a block with extra vertical margins". This is semantic in the Web Apps 1.0 draft, but whether it remains so in the real world will depend on who is faster: UA vendors distributing software that prominently takes advantage of the structure is supposed to provide, or eager tech Weblog authors misguidedly replacing all the occurrences of with in their templates in an attempt to be "more semantic". My money, regretfully, is on the Weblog authors. or If is retained, it will remain a presentational element for making text bold ad hoc, regardless of how the spec defines it. If is dropped, will become a de facto presentational element for making text bold ad hoc, regardless of how the spec defines it. (To a small extent this has already happened, thanks to those people who have given the impression that is naughty.)
Re: [whatwg] Thoughts on Context and Popup Menus for Web Applications
On 6 Jan, 2006, at 2:54 PM, Ian Hickson wrote: On Sun, 14 Nov 2004, Matthew Thomas wrote: On 11 Nov, 2004, at 5:11 AM, Matthew Raymond wrote: ... Who's to say the UA couldn't just append the menu to the context menu? Or append the browser context menu as a submenu? Reasonableness. Shortcut menus (aka context menus) become more difficult to use the more items they have (as closeness to screen edges require that they open in a direction other than southeast), and submenus of shortcut menus are extremely difficult to use for the same reason squared. Do you know of a method that could be used that would not suffer from these problems? The usual method is for the app developer to place a visible menubutton next to the relevant control (e.g. the list of mail folders in Apple Mail), next to the currently selected item (e.g. a selected e-mail address in Apple Mail), or inside the relevant text field (e.g. the search fields in Firefox, Safari, Thunderbird, and many other apps). These menus are much simpler than a UA-items-plus-app-items menu would be, because they don't contain the UA items. So one useful addition to HTML would be a way of specifying a menu for a text field, where a menu item is either a mode (with text and an optional icon) or text (which replaces the current contents of the field). The most common use case for this would be changing the scope of a search for the former, and choosing a recent search string for the latter. Another useful addition would be a way of recognizing part of the contents of a text field as an entity that has its own menu (maybe by specifying a set of characters as entity delimiters), so that the UA can display a menubutton next to that text when the item is selected (and also let an entity be selected in one click). The most common use case for this would be editing a list of keywords or tags applied to an item, like photos in Flickr, goals in 43 Things, posts in Weblogs, and so on. Probably the second most common use case would be to make addressing as easy in a Webmail app as it is in Apple Mail. As for placing menubuttons at arbitrary positions, that should be pretty simple once menubuttons are supported at all. ... I think we may be venturing into "no practical solution for the platforms some user agents are running on" territory again. This would be unfortunate. It is very clear that there is a need for Web applications to be able to provide context-sensitive commands. Windows Live Local (formely MSN Virtual Earth) provides a context menu on its maps, and it makes a lot of sense. Then that's very poor design on their part. Since that menu opens on mouseup, so it wouldn't interfere with a drag, they could just as easily require a normal click to open the menu rather than a right-click. As it is, a large proportion of people using Windows Live Local won't realize that those functions exist, because they require a right mouse button that such people either never use or (less commonly) don't have. Would we not want to allow a more semantic and accessible way of doing that? ... Context menus aren't particularly accessible no matter how they're implemented, since there's no hint that they even exist. A menubutton, though, could be tabbed to even if it had appeared only because the element it was inside had been selected or focused. -- Matthew Paul Thomas http://mpt.net.nz/
