Re: [whatwg] CENTER, MENU, DIR, NL; Re: Presentational elements in Web Applications 1.0
On Thu, 1 Nov 2007, Keryx Web wrote: I use it sometimes for a very small form, where I think p or hx is inappropriate and fieldset is overkill. As in form action=login.php method=post div label for=unameUsername:/label input type=text name=uname id=uname /div div label for=passwdPassword:/label input type=password name=passwd id=passwd /div /form Why is p inappropriate? According to HTML5, it's exactly the element you want, in fact. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] CENTER, MENU, DIR, NL; Re: Presentational elements in Web Applications 1.0
Ian Hickson is reading his mail so fast this almost feels like IM ;-) Why is p inappropriate? According to HTML5, it's exactly the element you want, in fact. a) To my linguistic senses that's not a paragraph b) I've seen several people use the div-element (like it or not). Should all their work suddenly be called non-conformant? My main example: http://simplyaccessible.org/article/search-form-layout Random examples: http://snipplr.com/view/3675/css-form-template/ Fieldset - div - inline http://www.webmasterworld.com/html/3247326.htm As to my (a) argument. Sometimes I could go with a list, as in http://www.alistapart.com/articles/prettyaccessibleforms Lars Gunther
Re: [whatwg] Use cases for data templates?
Apologies, but bump! Keryx Web skrev: Henri Sivonen skrev: * What's the use case for data templates? It is hard to review them without knowing what they are for. Conjecture-based comments/questions follow. I am also very interested in this question. I think there is a tendency to include too much in HTML - since that what developers know. Except for the case of repeating stuff on a multi-line form (already covered in Web forms 2) I have never felt the need for any client side template system, nor have I read of any app where this might be useful. BTW, will they degrade gracefully? Lars Gunther Who still wants a use case for templates at the front-end!
Re: [whatwg] SQL API and Transactions
On Oct 31, 2007 5:20 PM, Ian Hickson [EMAIL PROTECTED] wrote:
On Wed, 31 Oct 2007, Scott Hess wrote:
I think one could work around this within the current spec something
like:
var success = true;
db.transaction(function (t) {
t.executeSql('insert into x values (?)', [y]);
db.transaction(function (t) {
if (success) {
// This should be called after the outer transaction has completed.
}
}
}, function (e) {
success = false;
});
That's awful cumbersome, but if the need is seldom enough, it might be
reasonable.
Actually that wouldn't work because nested transactions are completely
independent of the initial one, so unless the transaction blocked the
entire database, the nested one above would finish immediately.
Hmm. Is this because we're allowing for what SQLite calls BEGIN
DEFERRED, rather than requiring BEGIN IMMEDIATE? [I'm basing this on
error code 5.] In that case, yes, the above won't work. I'd like to
argue that BEGIN IMMEDIATE should be required, but I don't think
that's at all portable.
-scott
Re: [whatwg] Menus, fallback, and backwards compatibility: ideas wanted
On Mon, 9 Jan 2006, Sander Tekelenburg wrote: At 01:21 + UTC, on 2006-01-09, Ian Hickson wrote: I constantly see friends, family, clients, strangers, colleagues struggle to figure out how to navigate through sites they don't know yet. Well sure, I struggle through such sites myself. The problem would not be aleviated by having a single point for site navigation, because the problem is just that the sites have poor structure. It doesn't matter how you _present_ the structure, if the structure itself is broken. True, that can also be a cause. But imagine for a moment a situation where at least the majority of browsers in use would have a nice NAV display:meta implementation, making it *visible* to people how they can organize the data they publish. Wouldn't that work as a guide, helping those who are not that well-organized realize how to publish their content in a more organised manner? No, not really, IMHO. Sites already have a big area where they can see their site, yet they make sites that are ugly and slow and unusable. Why would a tree (or other navigation representation) be any different? They might well think Ah, I can do like that other site: make a contact and a help page and tag 'm with display:meta to put them in that navigation thingy. I can even make sections that way to different parts of my site. k3wl. Why would they care? We haven't seen any evidence to suggest they would. That's how it works with most things: some technique becomes available in a nice and obvious form and suddenly people start using it. Usually, there's at least a rumbling of desire before it's made available. For navigation toolbars, there's been basically nothing. Browsers have implemented them, shipped them, then removed them because nobody cared. [display:meta] could be interesting if (and it's a big if!) you could convince browsers to implement it. I imagine it would be a logical step for Opera and Safari to take, given their activity in the hand-held/small screen market where something like this would probably be very useful. Well go and convince them and when you have some implementations we can add it to the spec. :-) My impression was that representatives of most browsers subscribe to this list. So I'm assuming they've already heard me. Maybe they're silently laughing at the nonsense I'm talking. Maybe they're already enthusiastically implementing it. I've no idea. I'm guessing not the latter, since it's been more than 18 months and we haven't seen anything new in this space. Anyway, I don't think we want to go back to the days where a browser defines its own new standards which other browsers are then forced to copy, faults included because by then too many authors/users are relying on that specific implementation. Makes more sense to me to all of us try to agree on something we think could work, and only then start work on (experimental) implementations and a spec. Experimental implementations and spec work should happen in parallel, otherwise we end up with standards that are theoretically perfect and practically useless. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] The link element and display: meta
As a general rule, the 'display: meta' discussion belongs in the CSS group's mailing list, not in the WHATWG mailing list. Having said that: On Mon, 9 Jan 2006, Sander Tekelenburg wrote: The problem is that link has throughly proven that there is little demand for such usability features from users. How has that been proven? The fact that the majority doesn't (yet) make use of something is hardly proof, is it? It's pretty close, though. :-) (Based on how I see people struggle with WWW navigation I would say there certainly is demand for something like this. I can't prove it, but it certainly seems obvious to me.) While I could see an argument for there being _something_ to help people navigate (if we had usability studies to suggest there was a problem), I'm not sure we can jump straight from there to the need of a navigation bar. After all, we'd need evidence that the navigation bar helps. Btw, that reminds me of something Apple did that I think confirms my idea that people find it hard to navigate the Web: Safari's SnapBack function targets exactly that issue. Does anyone use that? :-) Look at RSS. Pretty much everyone supports it, and link is much older. I don't see how that proves anything. If Navigator and Explorer 2.0 had supported LINK then probably every single site out there would be using it today. Authors and users using something, or even *recognising* that they 'need' something is often only made visible after it has been made available to them. The point I think is that RSS went from not existing to being implemented and widely used in less than than link has existed, indicating that link is not as good as RSS. The question is: why has link not been widely implemented, when other, newer things have? On Fri, 20 Jan 2006, Sander Tekelenburg wrote: Remember that the idea is that authors/users can tell a browser to present certain data in a manner that is consistent across sites. In today's browsers I think that indeed would only be possible by presenting it outside of the body, because each site's body is unique and thus cannot offer such consistency. Just saying 'display: meta' isn't enough for a browser to know what to display, though. HTML 5.0 defines a NAV element to indicate a navigation menu which is allowed to contain (sectioned) lists of links, and which may be (should be?) presented in a manner that is consistent across sites. nav will just be rendered as the site's style sheet says it should be rendered. CSS 3.0 defines a meta value for the display property, thus providing authors and users with a mechanism to suggest that a user-agent presents targeted elements as if they contain meta data, optionally (but in practice probably always) presented outside of the body, in such a way that it is easy for the user to access and is presented consistently across sites. Exactly how the *contents* of an element that is displayed meta are presented is up to the user-agent, allowing for a presentation that makes sense for a given browsing environment. (The spec could include a suggestion that a possible implementation would be a separate browser window, which the user may target with User CSS to effect his own preferred consistent presentation across sites.) I don't understand how the 'meta' value would know what to show or do. On Sun, 22 Jan 2006, Anne van Kesteren wrote: However, I'm still not sure what problem is being solved here. Indeed. On Sun, 22 Jan 2006, James Graham wrote: If I understood correctly, the problem that is being solved is loosely websites all look different and so are hard to navigate. Are we sure that Web authors actually want to solve this? Because without their involvement, this will be hard to fix. Am I correct? Assuming I am, the idea of display:meta or any other similar solution is doomed to fail for the same reasons that link has never really taken off (only the situation with display:meta would be much worse because it applies to all elements): 1. It doesn't make sites consistent. Even if we only consider display:meta being used to create native menus from navigation lists, each site would still have totally different items in a totally different order. In desktop applications, the consistency comes not so much from the fact that all menu bars look the same and appear in the same place (though that is important) but from the fact that it is possible to guess which items will be in which popup and what the function of each item will be (e.g. the Edit menu will _always_ start Undo, Redo, Cut, Copy, Paste... assuming those actions are supported by the application). On the web, there is inherently no such consistency (websites don't have nearly the same consistency of actions that desktop apps have) and it's hard to imagine a Web equivalent to Desktop UI Guidelines to bully site authors into providing a consistent
Re: [whatwg] Menus, fallback, and backwards compatibility: ideas wanted
On Mon, 9 Jan 2006, Sander Tekelenburg wrote:
Authors can only suggest presentation, in the end the *user* decides
on it. That's the essence of the Web. Thus we should not be thinking
merely about what authors want, but at least as much, and probably
more, about what users want.
As a user on a dual monitor 1600x1200 system, I certainly don't have
any issues with space for navigation...
{shrug} You still have the same problem: namely that the author of the
site cannot know that you have those 2 large screens.
Actually media queries make this information quite accessible.
At the moment, sites can (and do!) provide a view of their site,
customised to their site, on pages as appropriate for that page and
that site. For example:
http://www.google.com/support
...has links to other major Google pages in a sidebar at the top left,
links to related pages in the mid-left sidebar area, links to related
features at the bottom of the left sidebar, links to major subsections
in the middle of the page, a search form at the top right, links to
popular subpages in the sidebar to the right, alternative suggestions
below that, links to other related pages below _that_, and at the
bottom has links to links only loosely related to the main topic.
How would that page look if authored with your proposal?
The page wouldn't exist ;) It *is* entirely a navigation menu. There is
no other content there. In 'my proposal', Google wouldn't have to do
that anymore. It could offer all that navigational information on pages
that do have 'actual' content and leave it up to the user-agent to
present it in a useful manner.
That aside, I imagine your point is that there are so many links on that
page, and that they are grouped in sections. But I see no problem with
that. All those links together (assuming they all have a rel attribute
and are set to display meta) would in a simplest form be displayed
through some meta presentational mechanism as a long 'flat' list of
links to other sections. That list might be presented as a shorter list,
each with sublists - thus keeping the sections, provided sections are
marked up that way. But instead of a list it could be presented as
objects (iconized and/or text perhaps) for the 'root' items, each
offering their sub items through a contextual menu. Display the current
page in the center of the screen, with everything else around it. Arrows
pointing from the current page in the center could make the rel
concept quite visual. Whatever. All up to the browser vendor's
imagination. (I imagine objects with contextual menus pointing to sub
items could work well on a small screen, like with a hand-held device.
But it might work well with large-screen desktops too.) For extra
coolness it could be implemented like Mac OS X's Expose feature: hit
some F key and have the entire screen filled with floating objects
representing the pages the site's menu points to ;)
You could even turn it around. Imagine a Web page that offers both
actual content and such a complex navigation menu as your Google example
contains. A user-agent could present those navigational links as a Web
page in a separate browser window, maybe looking exactly like this
Google page. After all, display:meta would not require a Toolbar. It
would merely require *some* 'meta-mechanism' for presentating content.
(Consider lynx' LINK implementation for example - no toolbar, but it
works fine. Or consider iCab's Link Manager, which brings up a browser
window with a list of all links found in the currrent page.)
It would help to see an actual implementation of all this, to show that it
would in fact be better than Web pages having their own stuff.
Or take this page:
http://buzz.yahoo.com/buzz_log/entry/2006/01/07/2100/?fr=fp-buzz-img
[...] How would that page look if authored with your proposal?
Same as that Google page. (Except of course the links within the actual
text would remain there.)
These pages are very different from each other. Saying they should be
authored the same (especially when you've said one shouldn't exist)
seems very vague, and not at all concrete enough for me to spec something.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] SRC Vs. HREF
On Mon, 16 Jan 2006, Eugene T.S. Wong wrote: On Sat, 14 Jan 2006 12:00:21 -0800, Alexey Feldgendler [EMAIL PROTECTED] wrote: On Sun, 15 Jan 2006 00:19:22 +0600, Sander Tekelenburg [EMAIL PROTECTED] wrote: Just a thought: perhaps applicable elements (those with a non-empty title attribute) could have an optional src attribute containing a URL to the remote document? pTeal'c activated his abbr title=Dial Home Device src=http://www.whatwg.org/specs/web-apps/current-work/;DHD/abbr and so Hammond ordered the iris to be opened./p HREF attribute is more appropriate here, IMO. Sander, I like your idea. It seems very easy for designers and developers to learn how to use it because it takes something that is already familiar, and reuses it in a similar way. It's a smart idea. It's not clear to me what the goal of this is. What problem are we solving? I agree with Alexey. I think that it would make more sense to use HREF because it becomes even more familiar. I'm used to thinking of HREF as something that takes me to another place, and SRC as something that brings something here. Would it be appropriate to allow designers and developers to use SRC in LINK? For example: LINK SRC=MyStylesheet.css as opposed to: LINK HREF=MyStylesheet.css In the long run, if it becomes possible to easily make other elements linkable, then the learning curve would be much lower. While this may have been a good idea long ago, at this point I think the cost in lack of backwards compatibility is probably too high to make it worth it. (The activation energy of this change is too high.) On Tue, 17 Jan 2006, Alexey Feldgendler wrote: On Tue, 17 Jan 2006 06:13:43 +0600, Eugene T.S. Wong [EMAIL PROTECTED] wrote: Would it be appropriate to allow designers and developers to use SRC in LINK? For example: LINK SRC=MyStylesheet.css as opposed to: LINK HREF=MyStylesheet.css Some LINK elements bring something here, like CSS, and some take you to another place. Do you propose to allow interchangeable use of SRC and HREF attributes for LINK at the author's discretion? I'm afraid it will lead to misunderstanding and unneeded diversity. Me too. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
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/
