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] input placeholder=
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 input placeholder=foo as it would have done to input value=foo clearonfocus: 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 PLAINTEXT and LISTING 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] 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 menu. ... 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: head ... command id=copy label=Copy onclick=copy() command id=cut label=Cut onclick=cut() command id=paste label=Paste onclick=paste() /head ... menu type=toolbar command command=copy ... 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] img 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 canvas, 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: img width=35 style=height: 1em; title=Untranslated: 35.42 % alt= 35.42% untranslated src=/@@/red-bar / 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: img width=35 style=height: 1em; height=10 title=Untranslated: 35.42 % alt= 35.42% untranslated src=/@@/red-bar / 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 img is one that the spec today considers valid. Wouldn't canvas be the better way to do this? Indeed it wouldn't, because canvas 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 canvas 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] [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 input type=checkbox or select multiple 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] 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: div rel=help for=phone-numberpThe full number, including country code./p pExample: samp+61 3 1234 5678/samp/p/div 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 input type=file just for photos.
Is this the iphone's behavior? (earlier you said it doesn't implement
input type=file, 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] 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 label, 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 label 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 res://blahblahblah 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
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 section, 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 details 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/
[whatwg] ins, del, and mark 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 li dt or dd in del or ins elements because ul, ol and dl only allows list items as their direct child. ... Oh, but it's even worse than that. :-) ins, del, and mark 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: p ...br ...br ...br ins... /p p ...br/ins ...br ...br ... /p 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: p...ins.../pp.../ins.../p. Conversely, she might remove text from two adjacent paragraphs, and therefore collapse them into a single paragraph: p...del.../pp.../del.../p. 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. p...mark.../pp.../pp.../p/mark The real-world things that the ins, del, and mark 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 ins, del, and mark 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 a ... rel=help for=phone-number, to be consistent with the for= attribute in label. 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 label in that respect: we want to encourage authors to put label near the control to which it applies, but label already has for=. (label 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: div rel=help for=phone-numberpThe full number, including country code./p pExample: samp+61 3 1234 5678/samp/p/div 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 whatever rel=help for=x visible in that space whenever input name=x 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 blockquote 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 q.) As a result, authors usually use an a 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 a element with a for= attribute giving the ID of the blockquote or q 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 foo cite=url/foo with bar rel=citation for=id-of-foo, or dropping cite= altogether. Cheers -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] BIG 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
citei, emi, icite, idfn, iem, or ivar, 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] BIG 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] CENTER, MENU, DIR, NL; 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 font and center are the best way of addressing this. Right, because there's no semantic element that their absence tempts people to use instead. (Whereas omitting b and i would tempt people to use em for italics and strong for bold instead.) ... i 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 div used for grouping thematically related blocks, and p 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 p, inside form rows div, inside forms form. If we wanted to separat[e] thematically related ... parts of a form we wouldn't use p; we'd use fieldset, because that's *exactly* what fieldset is for. Cheers -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] img 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 canvas, 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: h1Burmese monks 'to be sent away'/h1 pledeThousands 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./lede 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 B element around the first paragraph of a story. But they also bolden the second paragraph, if it's explaining the source of the story: B...P.../B. http://news.bbc.co.uk/2/hi/asia-pacific/7018411.stm So to satisfy the use case of the BBC, lede 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: pstrong.../strong/p. 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 p tags entirely: b.../b. 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 menu. When this attribute is present, all the menu's items should be disabled, regardless of their individual disabled= attributes; when the menu'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: zcorpan_ http://www.thewebcreator.net/2007/04/16/why-you-should-be-using-html -401-instead-of-xhtml/#comment-23 (same article) Hixie the last comment on that blog entry highlights one of the weirdest things i've repeatedly seen on the web Hixie HTML 5.0 vs XHTML 2.0 (commercials companies vs W3C) Hixie 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 canvas support they already include in end-user products because a call-for-comments had been issued for the canvas 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/
[whatwg] input type=search
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 input type=search. 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 input type=search? 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 input type=search 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 error for=... element. 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 label, 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 details 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 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 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 titles, 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 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] 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/
Re: [whatwg] blockquote cite and q cite
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: a. So a backward-compatible way of citing sources would be an attribute that points to either a (if the full citation should be out of the flow of text), or to another element (if it should be inline). For example: pa id=q018 href=http://example.com/2007/01/21/c;Fred Mondegreen concurs/a: q source=#q018When you compare it with books, the Web is still a newborn baby/q./p pAs span id=q019Albert Einstein said during an interview in 1949/span: q source=#q019I do not know how the Third World War will be fought, but I can tell you what they will use in the Fourth — rocks!/q/p (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: q cite=URLTo be, or not to be/q, 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 cite
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/
[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 font. (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 li element. Pre-computing the values for all of them in a style element, then attaching the appropriate class= to each li, would not only be a lot of extra work, it would also involve either iterating through the list twice (once to calculate the sizes and construct the classes, once to actually render the list) or caching the items from the database, which would be a lot of extra work. We could add a font element around every list item, but that shouldn't be necessary. A more common example is tag clouds, where a computed size is given in the style= attribute of an a element. In that case, there is the same objection to using classes. And there is a more practical objection to using font: in a cloud that showed hundreds of tags, an extra element for each of them would add substantially to the size of the page. Cheers -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] Problems with the definition of cite
On Jan 17, 2007, at 12:46 AM, Benjamin Hawkes-Lewis wrote:
Matthew Paul Thomas wrote:
...
This is the correct way to do it:
pqThis is correct!/q, said citeIan/cite./p
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
dialog (wherein you can style dt to be italic), not cite.
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 cite 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=745161SiteID=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
cite) 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 cite 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 work -- 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 cite
entirely. If a semantic element is needed for citations, introduce a
citation element that legacy browsers won't italicize.
Cheers
--
Matthew Paul Thomas
http://mpt.net.nz/
Re: [whatwg] contenteditable, em and strong
On Jan 12, 2007, at 5:23 AM, Henri Sivonen wrote: ... The introduction of em and strong (circa 1993) has failed to achieve a semantic improvement over i and b, because prominent tools such as Dreamweaver, Tidy, IE and Opera as well as simplified well-intentioned advocacy treat em and strong merely as more fashionable alternatives to i and b. (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 h1..h6 instead of pb or pfont a bad idea? Is the effort to get people to use CSS instead of table for layout a bad idea? There were, I'm sure, many more occurrences of those problems than there were improper uses of em and strong. And the efforts to replace them are much older than the effort to get people who don't think about semantics to use b and i, which has hardly even started yet. Ten years ago, the typical Web developer probably didn't know what em and strong were. Now, the typical Web developer probably thinks that b and i 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 i and em 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, em and strong
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: ... strong and b 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 u. ;) 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 em. But in practice the choice between em and strong is motivated by the default visual rendering. I don't think there's anything wrong with that, in itself. It's shorter than emphasis class=italic and emphasis class=bold. :-) ... em, strong, i and b 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 i and b. This is where we really need results from Google Markup Search (paging Mr Hickson): What proportion of pages use em and/or strong, what proportion of these appear to be generated using a Wysiwyg tool, what proportion also use i and/or b, and can a sample of their URLs be provided for the purpose of surveying how often em and strong are used inappropriately? The message please use b and i unless you really know what you're doing, and generate b and i 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 i and b instead of em and strong. Being ambiguous, i and b are insufficient hooks for speech CSS styling by the author, at least not without additional classes.) em and i are exactly as stylable. strong and b 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 em and i 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] contenteditable, em and strong
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 b and i unless you really know what you're doing, and generate b and i 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 pbfoo:/b bar/p is likely a definition, pstrongfoo:/strong bar/p 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 b, not strong.) * 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 b and i equally versatile as the content models for strong and em. 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 b and i 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/
[whatwg] Problems with the definition of cite
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:
pcitea href=../a/cite ... q.../q/p
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 cites to blockquote
and q is not only a heuristic, it's a poor heuristic, because it will
fail often in those documents where blockquote and cite are used at
all. For example, it will fail where one cite element is in a
paragraph immediately between two blockquotes, when it may be the
citation of only one or neither of them.
There are other problems in WA1's current definition of cite
http://www.whatwg.org/specs/web-apps/current-work/#the-cite. It says:
This is the correct way to do it:
pqThis is correct!/q, said citeIan/cite./p
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 cite 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
cite, 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:
pMy favourite book is citeThe Reality
Dysfunction/cite by citePeter F. Hamilton/cite./p
This is correct, because even though the source is not quoted,
it is cited:
pAccording to citethe Wikipedia article on
HTML/cite, HTML is defined in formal specifications
that were developed and published throughout the
1990s./p
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 cite 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?
pMy favourite book is citeThe Reality Dysfunction/cite by
citePeter F. Hamilton/cite, because Hamilton describes
wormholes as a way of travelling over long distances./p
pMy favourite book is citeThe Reality Dysfunction/cite by
citePeter F. Hamilton/cite, because of Hamilton's
description of wormholes./p
pMy favourite book is citeThe Reality Dysfunction/cite by
citePeter F. Hamilton/cite, because of Hamilton's
descriptions of various sci-fi ideas./p
pMy favourite book is citeThe Reality Dysfunction/cite by
citePeter F. Hamilton/cite, because of Hamilton's
descriptiveness and imagination./p
pI arrived in Boston having read about half of Peter F.
Hamilton's latest book, citePandora's Star/cite. This is a
nearly 900 page book, part one of the citeCommonwealth
Saga/cite. I absolutely loved his first saga, the
citeNight's Dawn Trilogy/cite. So far this book is
promising to be just as good./p
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 cite element around its title.
I think a more compatible and visually obvious (if less semantically
obvious) definition of cite 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/
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 'dldtfoodt ddbar/dd/dl', '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 'pbfoo:/b bar/p', '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 dl in HTML 4, and p 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] 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 dl in HTML 4, and p 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] 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] 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, html title=PG-13? 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: img id=img1 src=... label for=img1 type=title.../label Here, label holds a value which should be treated the same way like the title attribute on img, 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 a elements. A link in a tooltip would usually be impossible to click. :-) -- 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/
[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 a, Google Sets with ul.) * Less presentational - more semantically-misused - less machine-analyzable - less utility. (Example: XHTML2's attempt to kill b and i, resulting in more misuse of strong and em.) 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] 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/
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 embed id=funnyVid ... caption for=funnyVidA funny video of a man being hit in the groin by a football/caption That would work for the current page layouts of YouTube and Google Video. I think what would work best for this is the figure element I've proposed back in june: figure captionSome caption here/caption ... /figure ... That would not. (At least, not without some tricky CSS.) -- 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: varE/var = varm/var · varcvarsup2/sup or maybe, as the speed of light is a constant, varE/var = varm/var · csup2/sup. ... 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 var needs to be expanded to include physical constants. -- 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] 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.) ... abbr title=that isi. e./abbr 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 abbr title=that isi.e./abbr 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 abbrOS/abbr abbr title=10X/abbr, I don't give abbrOS/abbr 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 select. ... Or, if you're using Web Forms 2 anyway, a datalist. -- 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 name 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* person
and au[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 html element. And we'll let the user easily override it if they want to. -- 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] 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 select whose selected item (and therefore its only visible item) was disabled would look entirely unusable. -- 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 command icon= should be part of CSS. Do you have any specific reason for wanting command icon= to be part 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 object src=. 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 select with script, or (b) implement their own with positioned elements and script. Introducing a third option, (c) use command 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] 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 img in documents where a meta name=generator... 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 meta name=generator... exception for compulsory alt=. -- Matthew Paul Thomas http://mpt.net.nz/
